Best way to track message sourced from existing record.

[chrisgrande]

I think I found a good way to handle this scenario — but wondering if there is a better way. 😃

I have a record representing an invite, I then send an email based on it's existence. I wanted to then update the original record with the message_id returned from the ESP post_send so that the status of the email sent can be connected to that original invite record.

I came up with adding a header to the outgoing message that has a UUID for the invite and then when the post_send signal fires I read the header back from the message, i.e. (message.extra_headers['invite-id'], using that to lookup up the original record and then adding the message_id to it.

I'm thinking this is the easiest, cleanest, way to hand this. Yes, no, maybe, I'm I off base?

Thank you!

[medmunds]

What you're doing should work. Extra headers are sent in the message to the recipient, so don't use this if invite-id needs to be kept private from them. One caution: some ESPs will reject non-standard email headers, so 'invite-id' could cause an error. Email standards allow all custom headers with an x- prefix, so 'x-invite-id' would be more reliable.

There are three other approaches you might consider. Whether they'd be easier or cleaner will depend on your code and your tastes…

First, you can add your own custom attributes to any Python object, so rather than using extra_headers you could just assign message.invite_id before sending, and then read that same attribute in your post_send signal receiver. (If you're currently using Django's send_mail convenience wrapper, you'd need to change that to construct an EmailMessage object and call message.send() instead.)

A second option is adding the sent message_id to your invite record immediately after sending, right in the code that sends the message, rather than in a separate post_send signal receiver. You can access message.anymail_status.message_id immediately after calling message.send().

Finally, a third option is to not bother with the ESP-assigned message_id, and instead have the ESP keep track of your invite-id for you. Anymail's metadata lets you attach custom data to a message to make it available in tracking webhooks. You would set message.metadata = {"invite-id": invite_id} before sending, and then access event.metadata["invite-id"] in your tracking signal handler.

[chrisgrande]

Thank you so much for the thoughtful answer! Looking at all the options I might go the metadata route, since I can then lookup that ID on the ESP side if needed for debugging. With calling message.anymail_status.message_id immediately after send, is it possible that might return AttributeError if the message hasn't sent yet — I'm not sure on the timing.

[medmunds]

This is one of the primary use cases for metadata, so that would be my first choice, too.

If you're tracking your invite-id in metadata, you might not even need to keep track of the sent message_id. But to answer your other question, Anymail adds the anymail_status attribute to a message as the very first step in attempting to send it. So that attribute will always be there immediately after message.send(), unless:

• You're not using an Anymail EMAIL_BACKEND. This frequently comes up running tests, where Django by default substitutes its own dummy backend. The Anymail docs discuss some options for testing your app if this is an issue.
• There's some problem initializing the email backend (e.g., invalid settings). In that case the send() call will raise some other error, before your code even gets to the line attempting to access message.anymail_status.

You can also use AnymailMessage as a drop-in replacement for Django's EmailMessage/EmailMultiAlternatives. It initializes message.anymail_status in its constructor, so it's guaranteed to be there from the beginning. (Using AnymailMessage is also helpful if your dev environment has type checking.)

There are some cases where message.anymail_status.message_id will be None (send() not called yet; message had no recipients so send just skipped it; not using an Anymail EMAIL_BACKEND), so you'd probably want to handle None if you're storing message_id.

[chrisgrande]

Thanks again! 😃

[zhaoketong]

based on the test environment , Webhook failed with status code 405