You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some cases where the local-to-session behavior does not work as desired. This generally is when the Sentry instrumentation is misconfigured or the SDK itself has incorrect behavior.
An example of this being an upstream problem can be seen in Remix:
We'll use this isue to track this concern and identify improvmeents to the heuristics.
One example improvement we could make is, when the behavior is unreliable (a flag maybe?), bias towards events that are seen only within a period of time since the session became active. We still have an upper bound issue there, but possibly a similar check could exist for that.
Another issue we might consider making is a flag to disable this feature. We might consider this feature experimental (albeit desired), so keeping it on by default would still be the goal.
Just some feedback from my experience using Spotlight for the first time.
We have a mono repo with a backend and 2 frontend projects. When I open the overlay in the frontend, all of the backend errors and traces are shown as from a different session, even when initiated from the frontend session I am viewing.
The backend correctly shows spans as part of the trace, so it does know the two are related.
There are some cases where the local-to-session behavior does not work as desired. This generally is when the Sentry instrumentation is misconfigured or the SDK itself has incorrect behavior.
An example of this being an upstream problem can be seen in Remix:
getsentry/sentry-javascript#9737
We'll use this isue to track this concern and identify improvmeents to the heuristics.
One example improvement we could make is, when the behavior is unreliable (a flag maybe?), bias towards events that are seen only within a period of time since the session became active. We still have an upper bound issue there, but possibly a similar check could exist for that.
Another issue we might consider making is a flag to disable this feature. We might consider this feature experimental (albeit desired), so keeping it on by default would still be the goal.
Refs #188
The text was updated successfully, but these errors were encountered: