You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
I can track (metrics, logs) when events are sent
If I can know the result, I can use that to take other actions (usually to log failures)
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.
@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.
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".
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 🥀
Activity
dcramer commentedon Sep 25, 2020
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:
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 commentedon Sep 25, 2020
@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
afterSendbecomes 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 commentedon Aug 17, 2021
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 commentedon Aug 26, 2021
Relates to: getsentry/sentry-dart#352
github-actions commentedon Oct 14, 2021
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: BacklogorStatus: In Progress, I will leave it alone ... forever!"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
peey commentedon Oct 15, 2021
bump