experiments: detect culled promotions by absence from /tracks, not its disabled field - #80
Conversation
…s disabled field The culled badge/hide shipped in #79 never fired: the backend's GetTracksWithVPSPool filters disabled tracks out entirely, so the /tracks response's disabled field is always false and an explicit-flag check can never match. The liveness signal is PRESENCE — every live bandit track is listed, so a promoted track missing from the list is culled/disabled (promoted tracks always run a VPS pool while alive; verified against prod: 25 live all listed, 15 dead all absent, zero possible misflags). Originals lose their badge: a control can be a live legacy pool-0 track this endpoint also omits, so absence proves nothing for them. An empty tracks list fails open.
Deploying lantern-dashboard with
|
| Latest commit: |
52c6878
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://0327b066.lantern-dashboard.pages.dev |
| Branch Preview URL: | https://reflog-culled-presence-check.lantern-dashboard.pages.dev |
|
Warning Review limit reached
Next review available in: 35 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR fixes culled-promotion detection in the Experiments overview by switching from an impossible disabled === true check (because culled/disabled tracks are omitted from /tracks) to using absence from /tracks as the liveness signal for promoted tracks, while keeping fail-open behavior on fetch failures/empty responses.
Changes:
- Replace promoted-track “disabled” detection with “missing from
/tracks” detection via aSetof live track names. - Remove original/control “disabled” badging and only badge promoted tracks as culled.
- Preserve fail-open guards so endpoint failures don’t hide/badge cards incorrectly.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
What
Fixes #79's culled badge/hide, which never fired (reported live: track 1672 / exp-80 disabled yet its card rendered unbadged).
Why it never fired
The backend's
/dashboard/trackshandler usesGetTracksWithVPSPool, which filtersdisabled = false— disabled tracks are absent from the response, and itsdisabledfield is therefore alwaysfalse. #79 checked for an explicitdisabled === true, which can never match.Fix
The liveness signal is presence: every live bandit track is in the list, so a promoted track missing from it is culled/disabled.
live promoted ∧ pool=0count is 0 — promotion always sets a pool).npm run buildclean; no new lint issues.