-
-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestions: Expose currentHub
getter
#1451
Comments
Hey @mokagio, how do you currently attach the stacktrace to the event? Can't you do something like? let event = Event()
event.stacktrace = Stacktrace(frames: [Frame], registers: [String : String])
SentrySDK.capture(event: event) I would be interested in why you attach stacktraces manually. |
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 "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
Any updates @mokagio? |
Hey @philipphofmann, I'm working on the same codebase as @mokagio and we're still stuck to using Sentry 6. In your snippet, which I'm copying below, you're suggesting that we set the stack trace manually: let event = Event()
event.stacktrace = Stacktrace(frames: [Frame], registers: [String : String])
SentrySDK.capture(event: event) Do you offer any mechanism to get the current |
I used a hack to obtain the stack trace in the PR referenced above, but it involves accessing private methods through selectors. It would be ideal to have a way to get the current threads for filling in the event. ☝️ |
Why do you want to manually attach a stacktrace to an event, @diegoreymendez? Can't you use the |
@philipphofmann - Because Sentry doesn't offer a callback after sending an event to know when sending the event succeeded, so we have to send the event manually to implement the callback ourselves. This means we need to create the event manually and add the stack trace info ourselves. Ideally this would all be resolved rather easily if what was originally requested here would be implemented. |
I just started the implementation of flush with #1013. Would that be sufficient for you? Or do you really need a callback after the event was sent? If so, can you please elaborate on your use case, @diegoreymendez? |
I'm guessing it could be enough. Thoughts @mokagio ? |
@philipphofmann thank you for following up on this!
We've been sending manual events as a way to track a certain type of runtime error within our apps to which the only followup was to force a crash. We achieve that behavior by manually serializing events and sending them to Sentry via HTTP call to the DNS The code pre-dates me, but I assume the reason for manually attaching the stack trace to the event is that it wasn't available at the time. I can check if it would be useful for you.
+1 on @diegoreymendez's comment. I left a question about whether you considered adding a completion closure. As long as we have a way to know the event(s) have been successfully sent, I think our use case would be satisfied. I'd be awesome to remove our custom code for this 🤩 |
Thanks for the info. Yes, with flush, you will know that the event(s) have been successfully sent. |
Question
Since version 7.x removed the
currentHub
andsetCurrentHub
fromSentrySDK
, what's the way to get a reference to the current hub now?Context
With version 6, we use the hub to get a reference to the current client and current scope in order to attach stack traces to events we log manually.
This relates to #660.
I suspect that, if there was an SDK-provided way to attach stack traces to events, we wouldn't need to access the hub.
Suggestion
Would it perhaps be possible to reintroduce the
currentHub
getter onSentrySDK
? Being only a getter method, it should be "harmless" for users to grab a reference and inspect its properties, right? I can see why you wouldn't want users to override the hub, as your docs say "The hub you are unlikely to be interacting with directly unless you are writing an integration or you want to create or destroy scopes," but, for us at least, having the ability to read what's in the hub is crucial.Thank you for your help 😄
The text was updated successfully, but these errors were encountered: