Closed mokagio closed 2 years ago
@mokagio Is this still a blocker for upgrading Sentry to 7.x? The Day One team was wondering if upgrading to the latest Sentry SDK is now possible.
Hey @spencertransier π Yeah, this is still a blocker. I haven't had time to look into how to rewrite or update our implementation to work around the APIs that were removed when going from 6.x to 7.x π
Maybe you or someone working on Day One can?
Here's two issues on the Sentry repo where we discuss about some options:
Maybe @jkmassel has some helpful ideas on where to start.
While looking at crash reports as part of the release management duties, I saw a notice from Sentry encouraging to upgrade to their latest version, 7.1.3.
I opened a WIP PR for it, but, unfortunately, there's a breaking change between 6.x and 7.x:
SentrySDK
doesn't expose thecurrentHub
method, which we use here and here as part of our custom flow to manually log errors with attached stack trace and running a completion block (see https://github.com/getsentry/sentry-cocoa/issues/660).Before opening an issue on the Sentry repo, I just wanted to double check here whether I may be missing something.
My current undersanding
We use that
currentHub
method to get the currentSentryHub
. The docs for this type are sparse:The docs also imply the average users is not supposed to interact with hubs, hence why they made the getter private, I'm guessing.
We use the hub only to get references to the current client and scope. We need an instance of the client because we call a method on it. I'm also pretty sure we need an instance of the scope. "The scope will hold useful information," if we were to init that ourselves because we can't get one from the hub, we'd lose all the current information.
The way forward
I looped through the autocompletion on
SentrySDK
andSentryHub
looking for a promising method to supplement what we can't do anymore, but came up short.I also run the demo app, hacking Tracks so that it would compile, to verify that
Client
responds to theprepareEvent:withScope:alwaysAttachStacktrace:isCrashEvent:
selector which is the one we built our shim around. If it didn't, we would have definitely have to go back to the drawing board, but luckily (?) it does.So, with the info I have at this point, the only way forward I see is opening an issue on the Sentry SDK repo, asking for help, ideally for reintroducing the
currentHub
method.Here's a draft:
What do you think, am I missing something? If not, does my question and suggestion for the Sentry team make sense? Is there anything that I could add to make it easier to understand?
Also, feel free to take a stab at the code in #180 to see if you can get it to work π
Thanks πββοΈ