Skip to content

Implement afterSend #2939

Closed
Closed

Description

@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.

Activity

  1. dcramer commented on Sep 25, 2020

    @dcramer
    MemberAuthor

    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.

  2. mitsuhiko commented on Sep 25, 2020

    @mitsuhiko
    Contributor

    @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.

  3. peey commented on Aug 17, 2021

    @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".

  4. bruno-garcia commented on Aug 26, 2021

    @bruno-garcia
    Member
  5. github-actions commented on Oct 14, 2021

    @github-actions
    Contributor

    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 🥀

  6. peey commented on Oct 15, 2021

    @peey

    bump

  7. locked and limited conversation to collaborators on Jan 25, 2023
  8. converted this issue into a discussion #6930 on Jan 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions