Implement afterSend

[dcramer]

We need a hook after an event is sent (likely also even when the event fails).

Needed data:

• event ID (event preferred)
• server result

Once this is implemented we need to update attachment and feedback examples to use this hook.

[dcramer]

It sounds like Relay may cause this to not be as effective as I'd like, but I think we should still add this. It should be more or less universal in any SDK, but if it can't be supported in some thats fine. It should always be "after the transport has delivered the event to the upstream Sentry server", even if that's e.g. after an application restart, or a week after the event happened.

There's a variety of historical use cases where this is valuable as a customer:

1. I can track (metrics, logs) when events are sent
2. If I can know the result, I can use that to take other actions (usually to log failures)
3. If I can know the result, I can optimize when i send additional metadata.

Additionally if we push things behind this afterSend hook, we can always come back later and find a way to optimize Relay to give more information to SDKs.

[mitsuhiko]

@HazAT let's have a chat about this on Monday. I want to revisit prior conversations about this issue with you.

The main motivator for not providing this is that afterSend becomes a complex topic particularly when events are passed from place to place. For instance react-native/native SDKs pass events to each other and then only get dispatched after restart in some cases. Some asks in the past were to attach a future/lambda directly to each event which does not survive these types of restarts. It's also that some use cases that people had about this before required the original context (thread locals etc.) to still be available which won't work as the events are sent delayed and in different places.

It might be possible to support for some simple cases and just say that the callback is not invoked/always invoked for situations where it can't otherwise work.

Having a general "afterSend" that might be possible if we don't guarantee when it's called, what the state about it is and that hints are no longer available. That does limit the usefulness of it, but might be good enough for some use cases. I would be curious though if this would support the use case still where attachments would be sent delayed.

[peey]

Adding to use-cases: being able to access the id in server result is useful to cross-reference sentry events with other data.

Currently to achieve that without logging excessive user information to sentry, only way is to generate a uuid on the server associated with the other data which is sent to sentry as part of "enrichment".

[bruno-garcia]

Relates to: getsentry/sentry-dart#352

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[peey]

bump