-
-
Notifications
You must be signed in to change notification settings - Fork 494
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
fix: Safe-navigate to session flusher #2396
base: master
Are you sure you want to change the base?
Conversation
We tried and it still fails: require "sentry/test_helper"
RSpec.configure do |config|
config.include Sentry::TestHelper
config.before do
setup_sentry_test { _1.auto_session_tracking = true }
end
config.after { teardown_sentry_test }
end |
Thanks for reporting the issue. It does look very puzzling as the only method that could nullify the session flusher is |
I am experiencing the same issue on production and hence reported #2378. Currently, the issue appears rather frequent for us, but not for each request: Is there any chance I could help to get this merged and released? Without a fix, each occurrence ends up with a 500 Internal Server Error and hides actually errors. I would rather miss a session tracing than having those errors. In our app, we never call |
We don't call |
Could you grab sentry from |
I tried the branch, but since we modified the codebase (where this issue normally occurred) a lot recently, I wasn't able to confirm the fix is working. Sorry for not being able to help out here. Maybe it's still valid to merge this PR using the safe navigation operator? |
We also took a workaround way by disabling session tracking completely. And even if we go back, the bug is pretty sporadic, to being able to tell if the patch in solnic/make-closing-thread-safe fixes the bug or no. |
Thanks folks. Would it be possible for you to disable your workarounds after we release a new version and see if it helped. The proposed fix here comes with a risk that it will silence actual failures where the session_flusher should really be there. It's kinda hard to tell which option would be worse but given that the fix addresses an edge case by making a change that may result in breaking more common cases (an actual misconfiguration of Sentry), then it's probably better not to apply the fix. |
As written above, I already tested the branch and partially reverted some of the code changes I considered to have the most impact on this issue. While I understand your concern, this issue (and especially the one discussed in #2428) may hide actually bugs from our code base as Sentry customers -- that happened at least for us. We would normally trust in the Sentry error reporting, but when this bug occurs, we lack any notification and insights on actual defects of our software. Hence, from our perspective, it is far less critical to miss some sessions than to miss the actual bug that occurred. |
Gotcha, thank you!
Alright, given that Hub is going away eventually (see #1495 (comment)) we can just rely on the workarounds here and in your PR for the time being. Thanks for all your input and help with this btw! |
@@ -248,7 +248,7 @@ def end_session | |||
|
|||
return unless session | |||
session.close | |||
Sentry.session_flusher.add_session(session) | |||
Sentry.session_flusher&.add_session(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.
Could you add a comment pointing to the related issue so that it's clear why we're doing this? 🙏🏻
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.
Will do so shortly.
Sure, we will give it a try! |
Sentry.session_flusher
isnil
-able. And under some circumstances (which I still can't figure out) in specs it'snil
causing our spec suite randomly (but as of recent, pretty all the time) fail.Example failure
RSpec Config (Sentry related)
Workaround
As a workaround, we just disabled session tracking:
Resolves: #2378