Skip to content

fix(killswitches): Always emit a metric if there is a match#107068

Merged
untitaker merged 1 commit intomasterfrom
ref/killswitch-metrics
Jan 27, 2026
Merged

fix(killswitches): Always emit a metric if there is a match#107068
untitaker merged 1 commit intomasterfrom
ref/killswitch-metrics

Conversation

@untitaker
Copy link
Member

Emitting a metric for every non-matched value is slow. But for the case
where we actually use the killswitch, we should always know how much we
dropped.

Emitting a metric for every non-matched value is slow. But for the case
where we actually use the killswitch, we should always know how much we
dropped.
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Jan 27, 2026
@untitaker untitaker requested a review from JoshFerge January 27, 2026 16:58
@untitaker untitaker marked this pull request as ready for review January 27, 2026 16:58
@untitaker
Copy link
Member Author

untitaker commented Jan 27, 2026

tagging @JoshFerge as IIRC he is the person who added emit_metrics flag.

@untitaker untitaker requested a review from a team January 27, 2026 16:58
Copy link
Member

@JoshFerge JoshFerge left a comment

Choose a reason for hiding this comment

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

makes sense, worth just keeping an eye on anything super high volume where we killswitch a lot for perf. regressions but seems unlikely to cause problems!

@untitaker
Copy link
Member Author

@JoshFerge

makes sense, worth just keeping an eye on anything super high volume where we killswitch a lot for perf. regressions but seems unlikely to cause problems!

I'm not aware of anything like that in our own uses of killswitches at least, but that's kind of the reason why i'm tagging you, if you know something like that where we keep a killswitch enabled now would be a good time to speak about it.

@JoshFerge
Copy link
Member

@JoshFerge

makes sense, worth just keeping an eye on anything super high volume where we killswitch a lot for perf. regressions but seems unlikely to cause problems!

I'm not aware of anything like that in our own uses of killswitches at least, but that's kind of the reason why i'm tagging you, if you know something like that where we keep a killswitch enabled now would be a good time to speak about it.

i'm not aware either, should be good!

@untitaker untitaker enabled auto-merge (squash) January 27, 2026 17:18
@untitaker untitaker merged commit 5aa4ecf into master Jan 27, 2026
67 checks passed
@untitaker untitaker deleted the ref/killswitch-metrics branch January 27, 2026 17:21
priscilawebdev pushed a commit that referenced this pull request Feb 2, 2026
Emitting a metric for every non-matched value is slow. But for the case
where we actually use the killswitch, we should always know how much we
dropped.
@github-actions github-actions bot locked and limited conversation to collaborators Feb 12, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants