Feature Flags Manual API

[adinauer]

Problem Statement

Add API for manually using Feature Flags feature to Java SDK.
As a follow up we can check which integrations would make sense and implement those.

Solution Brainstorm

https://develop.sentry.dev/sdk/expected-features/#feature-flags

[linear]

JAVA-188 Feature Flags Manual API

[adinauer]

Implementation Plan

• Scope based API
  • Add addFeatureFlag method to IScope
  • Add addFeatureFlag method to Sentry static API and IScopes
  • By default write to default write scope (isolation scope for backend, current scope for Android)
  • Add FeatureFlagsBuffer to IScope
    • Implement max limit of 100 items in buffer on Scope
    • Discard oldest entries if limit in buffer is reached
    • If key already exists, we update the value and move the item so it's discarded last (as if freshly added)
  • When a scope is cloned, we copy values over
  • Modifications on cloned scopes do not affect the parent
• Span based API
  • Add addFeatureFlag method to ISpan
  • Use FeatureFlagsBuffer with a limit of 10 per Span
    • When limit is reached we do not add anymore new keyed values
    • Existing entries will be updated even if limit reached
  • Child spans do NOT inherit parents feature flags
  • Scope Based API also writes to currently active span
• Merge feature flags from different scopes by dropping oldest and adhering to the limit
• Sending feature flags to Sentry
  • Add feature flags from scopes to flags context: https://develop.sentry.dev/sdk/data-model/event-payloads/contexts/#feature-flag-context
    • We do this only for events like errors, messages (TBD more?)
  • Send span feature flags as flag.evaluation.{flag} in span data
  • Feature flags from scopes are NOT sent in spans, only in events

[cmanallen]

@adinauer This checklist looks complete to me. One area of focus should threading. As with all things threading, you need to be careful here. Your feature flag buffer will branch like a tree as you enter new isolation scopes. Using immutable data-structures (like an HAMT if its available to you) will make things faster/easier otherwise you will need to copy the whole buffer for each new isolation scope created.

Maybe a subtle point that could have been missed but we don't isolate feature-flag evaluations by thread. We isolate by isolation scope. That is, a customer could, if they chose to, collect feature flag evaluations from multiple threads into the same shared object (so whatever data structure you choose to buffer flags must be thread-safe). Its up to the customer to enter a new isolation scope if they want to.

[bruno-garcia]

@sentry review
dogfooding time