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

Retry #36

Open
awdeorio opened this issue Jan 24, 2019 · 2 comments
Open

Retry #36

awdeorio opened this issue Jan 24, 2019 · 2 comments

Comments

@awdeorio
Copy link
Owner

Wait and retry in response to SMTP rate limiting. Include a configuration parameter to set the timeout.

@nickolay
Copy link

nickolay commented Nov 2, 2020

@awdeorio you said in #103:

I agree that reliable email delivery would be best implemented by starting with rendering all the templates into a folder.
In summary, I think that writing output to a folder is a niche use with a reasonable work-around. I don't think it makes sense as a stand-alone feature. I do think it makes sense as part of the bigger picture of reliable delivery #36. I'm goingg to close this issue in favor of continuing the discussion under issue #36.

Could you sketch out your thoughts on this please? I was planning on simply feeding all the generated eml files to a script that works with an individual message and either gets it accepted by the SMTP server or returns a non-zero error when giving up:

ls /path/to/*.eml | xargs -I{} bash -c "send.sh {} && mv {} {}.sent"

This would alert me when any of the messages failed to send, and would fix itself later in case of an intermittent error. A bad eml would require a manual intervention (removing it from the queue and possibly generating a fixed version).

@awdeorio
Copy link
Owner Author

I'm thinking something like this

  1. Create a directory RUNDIR
  2. Render all messages to individual plain text files in RUNDIR
  3. Send messages one at a time
    a. If success, move on the next message
    b. If failure, wait and then try again

Design decisions

  • Should we delete messages that have been sent successfully?
  • Where should RUNDIR be located?
  • Which specific SMTP exceptions should trigger a retry?
  • How long to wait between attempts?
  • Where to configure the delay between attempts and max retries?
  • What happens if mailmerge exits unsuccessfully for any reason? E.g., user hits Control-C, an exception occurs, an error in a database row. Delete RUNDIR and start over next time mailmerge is run? Start where you left off?
  • What happens if template or database changes in the middle of a retry? Should we copy the template, database, config, and attachments into RUNDIR?

Testing

  • Verify mailmerge --dry-run does not write any files
  • Directory creation, even with different PWD
  • Message render to files
  • Max retry
  • Delay between attempts
  • Directory cleanup(?) on success
  • Directory cleanup on error
  • Resume behavior on second run after error (pending design decision)

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

No branches or pull requests

2 participants