Skip to content

feat(flags): capture feature flag evaluations on spans #16485

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 17 commits into
base: develop
Choose a base branch
from

Conversation

aliu39
Copy link
Member

@aliu39 aliu39 commented Jun 4, 2025

Based off https://github.com/getsentry/sentry-python/pull/4280/files
Reopened from #16475

This PR updates our 5 browser FF integrations to capture flag evaluations on spans. This implementation avoids changes to the Span class, saving bundle size.

  • on eval, flags are added to span attributes. A global WeakMap is used to track the unique flags for a span. Updates to a flag's value is allowed.
  • staying consistent with the python PR:
    • we only capture values for the first 10 unique flags per span. Subsequent flags are dropped.
    • attribute keys have the format flag.evaluation.{flagKey}

From @AbhiPrasad :

A method on the span break our compat with OTEL spans, which we use for duck typing in some scenarios.

From @cmanallen :

For spans the oldest flag evaluations are the most important because they're likely to have the largest performance impact. We drop late arrivals due to request size concerns.

@aliu39
Copy link
Member Author

aliu39 commented Jun 5, 2025

@aliu39 aliu39 force-pushed the aliu/span-flags-v2 branch from 03699e5 to 7c2c161 Compare June 6, 2025 16:49
@aliu39 aliu39 marked this pull request as ready for review June 6, 2025 22:15
@aliu39 aliu39 requested a review from chargome June 6, 2025 22:15
Copy link
Member

@chargome chargome left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just one question: You need the buffer approach for determining the evaluation order right? Otherwise we could also just conditionally add the flag based on how many attributes are already present on the attributes.

* unique flags for a span reaches maxFlagsPerSpan, subsequent flags are dropped.
*
* @param name Name of the feature flag.
* @param value Value of the feature flag. Non-boolean values are ignored.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this expected to receive anything other than boolean in the future?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, though the work isn't planned yet. We have some backend support for non-bool but are choosing not to support it in the product atm, cc @cmanallen

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mobile is free to support it. We can add support at any time we wish. We've not explicitly scoped it for JS or Python but you're welcome to add it if you want.

@aliu39
Copy link
Member Author

aliu39 commented Jun 16, 2025

Looks good! Just one question: You need the buffer approach for determining the evaluation order right?

Yes, I originally used buffers/arrays to track the eval order as we do in the scope/errors. However I don't believe this is a requirement as we're not enforcing order in Python spans, only recording the first 10 unique flags. IMO it's not as valuable for the span usecase, and for only 10 flags.

Otherwise we could also just conditionally add the flag based on how many attributes are already present on the attributes.

Yes that would also work as an alternative to the global weak map. Is there a way to do this without extending the Span interface though?

@aliu39 aliu39 requested a review from chargome June 16, 2025 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants