Suggestions: Expose currentHub getter

[mokagio]

Question

Since version 7.x removed the currentHub and setCurrentHub from SentrySDK, 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 on SentrySDK? 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 😄

[philipphofmann]

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.

[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 🥀

[philipphofmann]

Any updates @mokagio?

[diegoreymendez]

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 Stacktrace without having to manually craft it ourselves?

[diegoreymendez]

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. ☝️

[philipphofmann]

Why do you want to manually attach a stacktrace to an event, @diegoreymendez? Can't you use the attach-stacktrace option?

[diegoreymendez]

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

[philipphofmann]

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?

[diegoreymendez]

I'm guessing it could be enough. Thoughts @mokagio ?

[mokagio]

@philipphofmann thank you for following up on this!

Why do you want to manually attach a stacktrace to an event, @diegoreymendez? Can't you use the attach-stacktrace option?

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 getEnvelopeEndpoint() API.

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.

I just started the implementation of flush with #1013.

+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 🤩

[philipphofmann]

Thanks for the info. Yes, with flush, you will know that the event(s) have been successfully sent.