-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(core): Deprecate session APIs on hub and add global replacements #10054
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
Conversation
packages/core/src/baseclient.ts
Outdated
@@ -721,7 +721,7 @@ export abstract class BaseClient<O extends ClientOptions> implements Client<O> { | |||
throw new SentryError(`${beforeSendLabel} returned \`null\`, will not send event.`, 'log'); | |||
} | |||
|
|||
const session = scope && scope.getSession(); | |||
const session = (scope && scope.getSession()) || getIsolationScope().getSession(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me a bit uncomfortable tbh, not sure if we for now should simply still use hub.startSession
in browser/node startSessionTracking
. But this change seems to be necessary for browser, since scope.getSession()
returned undefined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, is this correct in the new implementation, I wonder? Or should we simply always take the one from the isolation scope? 🤔 because the scope here would generally be the final scope being applied and can even be a temporary scope, like new Scope()
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thinking about this, I guess it doesn't hurt, if you pass a scope that actually has a session on it I guess it makes sense that we use this. But it will/should use the isolationScope in 99% of cases I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, is this correct in the new implementation, I wonder?
You mean that we set it onto the isolation scope? I think that should be correct 🤔
EDIT: But not "complete" (see answer below)
Or should we simply always take the one from the isolation scope? 🤔
I guess it would be more correct if we're okay with not supporting people adding their own session to their current scope 🤔 Not sure if that's even a thing...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, for v7 we probably still need to set the session also on the current scope, right? So that getCurrentHub().getScope().getSession()
still returns the session
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably makes calling getIsolationScope
obsolete here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm I guess so, you're right! :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reworked the top level APIs to also modify the current scope's session. For now this will work and spare us mocking with event processing
size-limit report 📦
|
const client = getClient(); | ||
const isolationScope = getIsolationScope(); | ||
|
||
const { release, environment = DEFAULT_ENVIRONMENT } = (client && client.getOptions()) || {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l: should we maybe just bail out if no client is found? Doesn't matter probably, but for clarity...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm thinking about this, if we do so, we have to return undefined
which I'm not sure we want to do. Also this means the signature of the replacement would slightly differ from the deprecated hub method. Since we're only taking env and release from the client I think it's okay to continue. Obviously, no
session will be sent but to me this aligns more with the concept of no-op spans for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, sounds good to me!
packages/core/src/exports.ts
Outdated
}); | ||
|
||
// End existing session if there's one | ||
const currentSession = isolationScope.getSession && isolationScope.getSession(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l: IMHO no need to check for getSession
existance, if you have code without this everything will fail here anyhow I guess xD
7c8f841
to
f392633
Compare
24181c7
to
566016d
Compare
…#10054) Deprecates and adds top-level replacements for * `hub.startSession` -> `Sentry.startSession` * `hub.endSession` -> `Sentry.endSession` * `hub.captureException` -> `Sentry.captureSession` These APIs were mostly used in browser and node `startSessionTracking` functions which were called on `Sentry.init`. I updated these usages with the global replacements and it seems integration tests are happy with it. For now, we not only put the session onto the isolation scope but also onto the current scope to avoid changing event processing and stuff like the ANR worker, as well as avoid "soft-breaking" users who use `hub.(get|set)Session`.
Deprecates and adds top-level replacements for
hub.startSession
->Sentry.startSession
hub.endSession
->Sentry.endSession
hub.captureException
->Sentry.captureSession
These APIs were mostly used in browser and node
startSessionTracking
functions which were called onSentry.init
. I updated these usages with the global replacements and it seems integration tests are happy with it.For now, we not only put the session onto the isolation scope but also onto the current scope to avoid changing event processing and stuff like the ANR worker, as well as avoid "soft-breaking" users who use
hub.(get|set)Session
.Also, it looks like we didn't have unit tests for session APIs before (but we did have integration tests). Therefore
hub.startSession
APIref #10033