feat(autoplay): instrument outcome eval to disambiguate #1275

[LucasSantana-Dev]

Context

#1275 (re-opened): autoplay rejected telemetry reads 0 all-time (269 rows) despite a working accepted path. The issue body's original "sub-5s dead zone" root cause is stale — #1276 (c282414) already records rejected for any skip <30% (and finish ≤30%), and the existing trackHandlers.spec.ts covers every classification band plus an interleaving "#1275 probe". So criterion #1 and #4 are already met, and a code race is largely ruled out.

What's left is empirical — H1 (code) vs H2 (signal genuinely rare) — and it can't be settled from the current logs: "Track skipped" only carries title/url, not the decision inputs.

Change (observability + tests only — no behavior change)

• Emit a structured Autoplay outcome eval INFO log for every autoplay terminal event on both playerFinish and playerSkip, carrying { path, guildId, trackId, hasStartTime, durationMS, playedRatio, recordedOutcome }. It fires even when the start time is missing (hasStartTime: false) — capturing the H1 race directly.
• recordedOutcome ∈ rejected | accepted | ambiguous(dropped) | none(no-timing) so Loki queries are one-liners.
• 5 new tests asserting the diagnostic shape across bands + the no-timing case + non-autoplay exclusion. Full suite: 25/25 green, type-check clean.

Why not "fix" now

Per the re-open analysis, patching the suspected non-bug would just add noise. This makes the prod distribution observable so the next read settles H1 vs H2.

After deploy — operator read (LogQL)

{container_name="lucky-bot"} |= `Autoplay outcome eval`

• Many recordedOutcome=ambiguous(dropped) or accepted on path=finish for real skips → H1 (skips route through finish / threshold mis-tuned) → then adjust.
• Few autoplay terminal events at all, most picks never played → H2 (signal rare; instrument is correct) → close as working-as-intended + revisit over-queueing.

Issue stays open pending that read; this PR does not close it.

Refs #1275

---

Summary by cubic

Add structured autoplay outcome diagnostics to investigate why rejected reads as zero in prod (refs #1275). No behavior changes; logs fire on both skip and finish with tests added.

• New Features
  • Emit Autoplay outcome eval INFO logs for autoplay terminal events on playerFinish and playerSkip (non-autoplay excluded).
  • Fields: { path, guildId, trackId, hasStartTime, durationMS, playedRatio, recordedOutcome∈rejected|accepted|ambiguous(dropped)|none(no-timing) }; logs even without a start time; playedRatio rounded to 3 decimals.
  • Outcome rules: < threshold → rejected; finish ≥ threshold → accepted; skip ≥ threshold → ambiguous(dropped). Tests: 5 cases cover skip/finish bands, no-timing, and non-autoplay exclusion.

^{Written for commit 7eb3f85. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lucky	Ready	Preview, Comment	Jun 17, 2026 7:11pm

[coderabbitai]

Warning

Review limit reached

@LucasSantana-Dev, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 36 minutes and 25 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 839d224e-db8b-4ff0-a605-f48dbe9ec819

📥 Commits

Reviewing files that changed from the base of the PR and between 4d57ac8 and 7eb3f85.

📒 Files selected for processing (2)

• packages/bot/src/handlers/player/trackHandlers.spec.ts
• packages/bot/src/handlers/player/trackHandlers.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/autoplay-reject-telemetry-diag-1275

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Failed to generate code suggestions for PR

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[cubic-dev-ai]

No issues found across 2 files

<sub>Auto-approved: Adds only diagnostic logging and tests for autoplay outcome telemetry, with no business logic changes.

Re-trigger cubic</sub>

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
96.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud