fix(queue): refuse a plugin's repeat while the queue slot owns playback - #503
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthroughQueue routing now consumes repeat events when a queue slot owns playback and reports an unsupported-source status. Events without queue ownership continue through normal routing. Streaming tests cover both paths. ChangesQueue repeat handling
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change narrowly prevents repeat commands from affecting playback owned by the queue slot; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
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 |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Summary
Closes the second half of #376. After #390 closed the internet-radio path, a plugin's
set_repeatstill reached the user's real Spotify device whenever the native queue slot owned playback:Action::SetRepeatdispatches a rawIoEvent::Repeat, no router consumed it, andNetwork::repeatchanged repeat on a track the user was not listening to, with nothing on screen to show for it. This is reachable in a plaindefaultbuild.The fix is a
Repeatarm inroute_queue_event, gated onqueue_owns_playback(). That router is compiled unconditionally and runs first in the pump, so it covers the Spotify and decoded queue slots in one place without touching the per-source dispatchers. It sets the same "Repeat does not apply to this source" status the keyboard path uses, so the plugin caller gets the same answer as the key.set_shuffledoes not have the same hole:Action::SetShufflegoes throughApp::shuffle, which already carries the queue-slot guard.Testing
cargo fmt --all -- --checkcargo clippy --no-default-features --features telemetry,tui -- -D warnings: cleancargo test --no-default-features --features telemetry,tui: 906 passedcargo clippy -- -D warnings: cleancargo test: 1208 passed, including the newrepeat_is_refused_while_the_queue_slot_owns_playback(gated onstreaming, since the slim build'sQueueNowPlayinghas no variants)tools/check_gates_ratchet.sh origin/main: okNot verified: a live run with a Lua plugin calling
set_repeatover a queued track.Additional notes
test_attribute_totalmoves 1770 to 1771 intools/gates.countfor the new test.💬 Questions or want to chat with other contributors? Join the spotatui Discord.
Summary by CodeRabbit
New Features
Tests