Open
Description
Use case:
- get a user id when the request is initially parsed (eg. from an
Authorization
header), and callscope.set_user({'http-username': 'bob'})
- later during request processing, get some more user information (say, email), and do
scope.set_user({'email': 'test@example.com'})
. Lets assume the request/headers aren't available at that point to re-retrievehttp-username
. - the later call replaces existing data in the scope (ie: the event ends up with only
{'email': 'test@example.com'}
) - same applies to other context sections (via
scope.set_context('section', {'some': 'value'})
)
AFAICT there isn't even a way to get the current user/contexts out again in order to manually merge them except via internals (scope._user
/scope._contexts['a_section']
). The framework integrations all seem to append to the user data, but that seems to happen much later in the processing.
Would it be worth exposing getter properties/methods, add scope.merge_*()
methods (which call dict.update()
), add merge=True|False
parameters to set_user()
& set_context()
, or something else equivalent?
Activity
github-actions commentedon Jan 5, 2022
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it
Status: Backlog
orStatus: In Progress
, I will leave it alone ... forever!"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
rcoup commentedon Jan 6, 2022
@sl0thentr0py I can potentially do a PR for this, but need some direction on which option is preferred
sl0thentr0py commentedon Jan 6, 2022
Hi @rcoup, user facing API changes need to be discussed internally first. A lot of folks are on vacation right now. I'll try to get back to you with more info next week.
set_tags
missing from python SDK #1344sentrivana commentedon Jul 4, 2023
Note for later: https://develop.sentry.dev/sdk/unified-api/#scope
We're currently not doing what the documentation states, so we should probably change this in the next major.
set_user
should not overwrite existing user data #2742