(1) Add new scopes related API (but not yet calling it) #2609
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Moved some functionality from Hub to Scope or Client: - moved `add_breadcrumb` from Hub to Scope - moved session functions from Hub to Scope - moved `get_integration1` from Hub to Client. This is preparation work for refactoring how we deal with Hubs and Scopes in the future. Each commit is moving one function, so it should be easy to review commit by commit.
…)` (#2570) Improves the capabilities of our threadlocal context variables, we use when no "real" context variables are available (for example in old Python versions) - Adds a no-op [copy_context](https://docs.python.org/3/library/contextvars.html#contextvars.copy_context) function to use in environments without context vars - Adds [reset](https://docs.python.org/3/library/contextvars.html#contextvars.ContextVar.reset) functionality to our threadlocal based context vars. This is preparation work for refactoring how we deal with Hubs and Scopes in the future.
Moved some functionality from Hub to Client: - Capture Event: - moved `capture_event` from Hub to Client - created new `capture_event` in Scope that calls `capture_event` in Client - made `capture_event` in Hub call the new `capture_event` in Scope - Capture Exception: - created new `capture_exception` in Scope - made `capture_exception` in Hub call the new one in Scope - Capture Message: - created new `capture_message` in Scope - made `capture_message` in Hub call the new one in Scope - renamed `**scope_args` to `**scope_kwargs` because it contains keyword arguments. - moved `_update_scope` from Hub to Scope and renamed it to `_merge_scopes` This is preparation work for refactoring how we deal with Hubs and Scopes in the future. Its properly easier to reason about this change when checking out the branch than looking at the diff.
Moved some functionality from Hub to Client: - sorted some typing imports - moved `get_traceparent` from Hub to Scope - moved `get_baggage` from Hub to Scope - moved `iter_trace_propagation_headers` from Hub to Scope - moved `trace_propagation_meta` from Hub to Scope This is preparation work for refactoring how we deal with Hubs and Scopes in the future.
antonpirker
changed the title
This was referenced Dec 19, 2023
Closed
sl0thentr0py
requested changes
Dec 20, 2023
…on into new-scopes-add-api
adinauer
reviewed
Feb 7, 2024
sentrivana
reviewed
Feb 9, 2024
sentrivana
reviewed
Feb 9, 2024
sentrivana
reviewed
Feb 9, 2024
sentrivana
reviewed
Feb 9, 2024
Co-authored-by: Daniel Szoke <szokeasaurusrex@users.noreply.github.com>
…lity of the sdk here
Co-authored-by: Ivana Kellyerova <ivana.kellyerova@sentry.io> Co-authored-by: Daniel Szoke <szokeasaurusrex@users.noreply.github.com>
…on into new-scopes-add-api
|
Closing this PR in favor of #2610 All the changes from this PR are in the linked PR now. |
antonpirker
added a commit
that referenced
this pull request
Feb 26, 2024
This refactors the SDK to move away from the Hub and have all the functionality in the Scope. Introducing different types of scopes. This aligns the SDK with how Opentelementry (OTel) handles data bringing us closer to be 100% OTel compatible. This change was discussed in this RFC: getsentry/rfcs#122 There is also a small FAQ: https://gist.github.com/mitsuhiko/1bc78d04ea7d08e5b50d27e42676db80 And a Miro board showing how the new scopes manage data: https://miro.com/app/board/uXjVNtPiOfI=/?share_link_id=216270218892 ### This RP contains - Introduction of global, isolation, and current scope - Deprecation of the Hub - All existing Hub based API still works and is still used by most of our integrations. Under the hood the new Scopes are used. - (this PR now includes all the changes made in the [first PR](#2609) introducing the new API) ### Breaking changes - The Pyramid integration will not capture errors that might happen in `authenticated_userid()` in a custom `AuthenticationPolicy` class. - The parameter `propagate_hub` in `ThreadingIntegration()` was deprecated and renamed to `propagate_scope`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds the API for the new Scopes to the code base but does not call/use it.
The ideas behind the new Scopes implementation:
ContextVarswith new_scope()andwith isolated_scope()the current and/or isolation scope are forked (meaning copied) and given to the code block wrapped with the context manager. On exit of the code block the current and/or isolation scope are reset to the old value that they had before the with block. (This is basically the same functionality as the push and pop scope of the stack in the current implementation)original_scope). We need this to implement copy-on-write functionality in forked scopes. As long as you do not change the data in the forked scope, all the data in the forked scope is still the same references as in the original scope. If you manipulate the data, a copy of the data is made and this copy is then changed. (implemented in the_copy_on_writedecorator, that will be applied to the properties of the Scope when the API is actually implemented. (this PR))NoopClientmeaning it can be used as a normal client, but it will not send any data to Sentry.There is a follow up PR where the API added in this PR is actually implemented: #2610