Skip to content

Commit fd1e866

Browse files
committed
Add develop docs documentation
1 parent 87c7e58 commit fd1e866

File tree

1 file changed

+21
-0
lines changed

1 file changed

+21
-0
lines changed

develop-docs/sdk/expected-features/index.mdx

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -91,6 +91,27 @@ Local variable names and values for each stack frame, where possible. Restrictio
9191

9292
This functionality should be gated behind the `includeLocalVariables` option, which is `true` by default.
9393

94+
## Feature Flags
95+
96+
An SDK may expose a Scope property for tracking feature flag evaluations. When the scope forks its important to clone the feature flags property. Leaking flag evaluations between threads could lead to inaccurate feature flag evaluation logs.
97+
98+
The Scope's flag property should have a capped capacity and should prefer recently-evaluated flags over less-recently-evaluated flags. The recommended data structure is a LRU-cache but it is not required so long as the data structure behaves similarly. Serious deviations from the behavior of an LRU-cache should be documented for your language.
99+
100+
The Scope's flag property should expose two methods: `get/0` and `set/2`. `set/2` takes two arguments. The first argument is the name of the flag. It is of type string. The second argument is the evaluation result. It is of type boolean. `set/2` should remove all entries from the LRU-cache which match the provided flag's name and append the new evaluation result to the end of the queue. `get/0` accepts zero arguments. The `get/0` method must return a list of serialized flag evaluation results in order of evaluation. Oldest values first, newest values last. See the <Link to="/sdk/data-model/event-payload/contexts/#feature-flag-context">Feature Flag Context</Link> protocol documentation for details.
101+
102+
### Integrations
103+
104+
Integrations automate the work of tracking feature flag evaluations and serializing them on error context. An integration should hook into third-party SDK and record feature flag evaluations using the current scope. For example, in Python an integration would call `sentry_sdk.get_current_scope().flags.set(...)` on each flag evaluation.
105+
106+
An integration is also responsible for registering an "on error" hook with the Sentry SDK. When an error occurs the integration should request the current scope and serialize the flags property. For example, in Python an integration might define this callback function:
107+
108+
```python
109+
def flag_error_processor(event, exc_info):
110+
scope = sentry_sdk.get_current_scope()
111+
event["contexts"]["flags"] = {"values": scope.flags.get()}
112+
return event
113+
```
114+
94115
## Desymbolication
95116

96117
Turn compiled or obfuscated code/method names in stack traces back into the original. Desymbolication always requires Sentry backend support. Not necessary for many languages.

0 commit comments

Comments
 (0)