API: any way to ensure a message is not created multiple times? #3002
Unanswered
quaaantumdev
asked this question in
Help with using Postal
Replies: 1 comment
-
I have also seen this referred to as idempotency. I don't believe Postal has any capacity to do this, it just sends everything it is asked to. I would like to hope that message IDs are unique in reality but I don't know enough about the SMTP spec to say for sure. It would definitely be a nice feature to have as a backstop for some out of control code but I don't know how much effort it would be to implement. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Questions:
Is there any to give the API an ID to ensure any future call using the same arguments does not create another message?
Why?
Modern compute infrastructure often uses the at-least-once delivery. Meaning a piece of software can be sure it is called at least once but may be called multiple times as the caller might miss the success/error response due to various network/software issues. (https://www.cloudcomputingpatterns.org/at_least_once_delivery/)
How?
The simple solution to this is, to put the de-duplication resposibility somewhat on the caller. The caller shall provide some an ID (propably some kind of hash, choosen by the caller), that the caller sees as unique. Postal should then check if the ID is already present in the system, if so, return an HTTP 409 Conflict or something like that. If not yet present, handle the message.
Already there?
I looked into the source code, without knowledge in ruby, and i think Postal may do something like that already when calling the /api/v1/send/raw API with a message-id created by the caller. Creating an RFC complaint message is kind of the think i'd really love Postal to do.
Is there any way to do this with the regular send API?
Only needed for a few days
It would be fine if such a conflict is only managed for messages of the last few days, so there is no need to store these IDs beyond the configured storage duration of other for the message.
Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions