Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

put failsafe limits on MTT #232

Open
tttp opened this issue Dec 20, 2023 · 3 comments · May be fixed by #252
Open

put failsafe limits on MTT #232

tttp opened this issue Dec 20, 2023 · 3 comments · May be fixed by #252
Assignees

Comments

@tttp
Copy link
Member

tttp commented Dec 20, 2023

Currently, if you by mistake change the end date to a date close to now and there are still emails to sent, it will try to push them all, risking a flood and blacklisting

When checking for emails to send , add a limit to no more than PROCA_MAX_HOURLY_EMAIL (environment variable, adjust the name to make it more proca way of doing things if needed) defaults to 99 emails per hour. and no less than 1,

so if the campaign setting is set to send from 1st of april to the 30 of april from 9am to 17h (30 daysx10 hours):

  • if on the 1st of april at 8am there are 30 emails to send, don't spread them over the next 30 days until the end of the campaign (and send 1 per day), send minimum 10 on the first of april (one per hour), 10 on the second and 10 on the 3rd), hopefully there will be more coming for the rest of the campaign
  • if on the 30st of april at 16h, we get 200 emails, we send only 99 and don't send the final 101.

the aim of the later is to prevent spamming the target "too much" if there is a mistake on the setting or when we change the end date/hour.

v2/unless trivial: Put another limit of how many emails per target can be sent in total (global default, can be overwritten by campaign), max 10k

@hiemanshu while you look at the current code, can you confirm it does properly spread sending the emails over the sending period queried (one hour) vs sending all the batch at the start of the hour?

@tttp
Copy link
Member Author

tttp commented Feb 19, 2024

to put more context:
in the future, we would want to adjust the way the emails are spread over the day: right now it has a start and end date, if the future, we probably wants something smarter, for instance avoiding going from 0 a start -1hour to the same flat max during "sending hours" dropping to 0 at end + 1 hour.

@tttp tttp changed the title put failsafe limits put failsafe limits on MTT Feb 19, 2024
@tttp tttp assigned destag and unassigned hiemanshu May 18, 2024
@destag destag linked a pull request Jun 12, 2024 that will close this issue
@tttp
Copy link
Member Author

tttp commented Jun 16, 2024

@destag ,

I'm wondering if we aren't taking this in the wrong order.

we have a delivery that tries to avoid flooding the recipients by spreading the sending over time until the end of the period, but we have to plan that failsafe because we might still have case where we have too many emails to spread over too little time

I'm wondering if a better approach is not to limit how many email each recipient can receive over the next cycle (say 10 min)

that way we can adjust based on each campaign strategy, and have a max email per cycle that is close to how the actions are distributed over time (so 0 between 1am and 6am, 10 email/h between 11 and 1am and 6am and 8am with a max of 60 email/hour at 10-12 and 14-18h (we can use the data we have)

@destag @1v4n4 to be discussed ;)

@1v4n4
Copy link
Member

1v4n4 commented Jun 16, 2024

0 between 1am and 6am, 10 email/h between 11 and 1am and 6am and 8am with a max of 60 email/hour at 10-12 and 14-18h
More questions:

  • Should we prioritize leftovers or newcomers or is it not important if we do not send all the emails during some period?
  • If we change the text of the campaign because the situation has changed, what do we do with old not sent emails?
  • If we extend the campaign after some time, and we have emails not sent...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants