Open sl0thentr0py opened 2 years ago
I think this is counter-intuitive and probably should be considered a bug.
After testing this, I think the actual problem is: should with_scope
capture exceptions?
If it should, then we can
(Because we now flag captured exceptions, it won't cause duplicated reporting)
If it shouldn't, we need to not popping the scope so other integrations (e.g. Rack middleware) can capture it with the inner scope's data. However, this can lead to other issues like polluting the request transaction
Ofc, we can also just keep the current behavior.
@st0012 so there are some things to consider here.
with_scope
belongs to the Unified API so we can't just change it outright, even though I personally don't like these semantics.try_with_scope
(name could be better potentially)with_scope
across SDKs and then eventually remove it in some major.Don't other SDKs have the same issue? What are their solutions to this?
Yes the issue is the same across SDKs, so we can drive the change process by doing it in ruby first. But we cannot change the old with_scope
, so it will have to be a new API.
That's fair. I'm not rushing to change it to be clear.
Will adding a keyword argument to with_scope
be an option? Like Sentry.with_scope(capture: true) { }
hmm yea good point! As long as the old behavior is preserved/backward compatible, we should be good.
Wait, this isn't how with_scope
is supposed to be used? Then how in the world is it supposed to be used? The docs are so absolutely bare bones of examples.
I am interested to work on this one and add the option to "capture". But I think it should be the default on a major version.
Creating this issue for further discussion.
If you do the following, the exception will be captured but the tag won't be used (because that scope is thrown away in an ensure).
If you do the following, the exception will be captured and the tag will be visible.
Originally posted by @sl0thentr0py in https://github.com/getsentry/sentry-docs/pull/5328#issuecomment-1194148134