queue: set schedule time for custom queue pushes - #93
Conversation
Signed-off-by: Chao Wang <cclcwangchao@hotmail.com>
📝 WalkthroughWalkthroughCustom queue task adapters ( ChangesQueue scheduling metadata and config accessors
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Caller
participant TaskInjector
participant LocalQueue
participant TaskQueue
Caller->>TaskInjector: push(task_cell)
TaskInjector->>TaskInjector: set extras.schedule_time = now()
TaskInjector->>TaskQueue: forward stamped task_cell
Caller->>LocalQueue: push(task_cell)
LocalQueue->>LocalQueue: set extras.schedule_time = now()
LocalQueue->>TaskQueue: forward stamped task_cell
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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.
🧹 Nitpick comments (1)
src/queue/custom.rs (1)
142-148: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueMinor duplication across push implementations.
The stamp-then-forward body (
task_cell.mut_extras().schedule_time = Some(now()); self.queue.push(task_cell);) is now identical inTaskInjector::push,LocalQueue::pushhere, andmultilevel::LocalQueue::push. Could extract a tiny shared helper (e.g. a free function or trait default) to avoid triple maintenance if the stamping logic ever changes.Also applies to: 174-180
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/queue/custom.rs` around lines 142 - 148, The push bodies in TaskInjector::push, LocalQueue::push, and multilevel::LocalQueue::push are duplicated; extract the shared “stamp schedule_time then forward to queue.push” logic into a small common helper or trait default method. Update LocalQueue::push and the other push implementations to call that shared helper so the scheduling stamp stays consistent in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/queue/custom.rs`:
- Around line 142-148: The push bodies in TaskInjector::push, LocalQueue::push,
and multilevel::LocalQueue::push are duplicated; extract the shared “stamp
schedule_time then forward to queue.push” logic into a small common helper or
trait default method. Update LocalQueue::push and the other push implementations
to call that shared helper so the scheduling stamp stays consistent in one
place.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: db9a04b8-f84b-4157-afba-8c0266892965
📒 Files selected for processing (3)
src/pool/worker.rssrc/queue/custom.rssrc/queue/multilevel.rs
| use super::{ | ||
| multilevel::{MultiLevelMetrics, TrackedRunnerBuilder}, | ||
| PopResult, | ||
| multilevel::{now, MultiLevelMetrics, TrackedRunnerBuilder}, |
There was a problem hiding this comment.
Should we move these crates to some common lib? Introducing multilevel here is a bit strange.
Non-block
There was a problem hiding this comment.
maybe we can do it in another PR
What changed
This PR updates the custom queue adapter to set
Extras::schedule_timebefore forwarding tasks through bothcustom::TaskInjector::pushandcustom::LocalQueue::push.It also exposes read-only getters for
multilevel::Config, so callers that build custom queues can reuse the multilevel defaults without duplicating them.Finally, it relaxes a worker wake test to assert the scheduling guarantee instead of an exact
resumecount. The exact count is timing-sensitive because a lateensure_workerscan wake an already-idle worker again after the task has been handled.Why
Built-in queues set
schedule_timewhen a task is pushed, and tracked runners rely on it to report queue wait time. Custom queues already reuse the same tracked runner metrics, but their adapter did not initialize this timestamp before handing tasks to the user-provided queue.Without this, custom queues can miss schedule-wait accounting even when the task itself uses multilevel-compatible extras.
Tests
cargo fmt -- --checkRUSTFLAGS="-D warnings" cargo clippy --all --all-features -- -D clippy::allRUSTFLAGS="-D warnings" cargo test --all --all-features -- --nocaptureRUSTFLAGS="-D warnings" cargo bench --all --all-features -- --test