Repository navigation
fix #320, #323: saturating_duration_since in learner promotion + expose ClientApi in embedded mode - #355
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughReplaces Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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)
d-engine-core/src/raft_role/leader_state.rs (1)
3664-3668: Nice fix; consider reusing the computed duration once.This is correct as-is. As a small cleanup, compute elapsed once and use it for both logging and the stale-threshold condition.
♻️ Small refactor
- trace!( - "Inspecting entry: {:?} - {:?} - {:?}", - entry, - now.saturating_duration_since(entry.ready_since), - &config.stale_learner_threshold - ); - if now.saturating_duration_since(entry.ready_since) > config.stale_learner_threshold - { + let elapsed = now.saturating_duration_since(entry.ready_since); + trace!( + "Inspecting entry: {:?} - {:?} - {:?}", + entry, + elapsed, + &config.stale_learner_threshold + ); + if elapsed > config.stale_learner_threshold {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@d-engine-core/src/raft_role/leader_state.rs` around lines 3664 - 3668, Compute the elapsed duration once into a local variable and reuse it for both the log and the stale check: replace repeated calls to now.saturating_duration_since(entry.ready_since) with a single let elapsed = now.saturating_duration_since(entry.ready_since) and then use elapsed when comparing to config.stale_learner_threshold and when passing to the logger; update the references around entry.ready_since, now, and config.stale_learner_threshold accordingly (e.g., in the block containing the stale learner condition).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@d-engine-core/src/raft_role/leader_state.rs`:
- Around line 3664-3668: Compute the elapsed duration once into a local variable
and reuse it for both the log and the stale check: replace repeated calls to
now.saturating_duration_since(entry.ready_since) with a single let elapsed =
now.saturating_duration_since(entry.ready_since) and then use elapsed when
comparing to config.stale_learner_threshold and when passing to the logger;
update the references around entry.ready_since, now, and
config.stale_learner_threshold accordingly (e.g., in the block containing the
stale learner condition).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 01b4672e-78a1-47b4-aba6-3216c0612d7d
📒 Files selected for processing (2)
d-engine-core/src/raft_role/leader_state.rsd-engine-server/src/lib.rs
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
…arner promotion Instant::duration_since panics if the argument is later than self (e.g. under VM snapshots or certain NTP adjustments). saturating_duration_since returns Duration::ZERO instead, making the stale-entry cleanup safe under clock anomalies. Three call sites in leader_state.rs: stale retain filter and stale-detection loop (both trace log and threshold check).
…-engine-server Embedded-mode users had no way to use ClientApi as a trait bound without adding d-engine-client as a separate dependency. Since EmbeddedClient already implements ClientApi, the trait itself should be accessible from the same crate.
65a0f03 to
71a6d32
Compare
What Does This PR Do?
Two independent small fixes: prevents a potential panic in learner promotion
logic under clock anomalies, and exposes
ClientApidirectly fromd-engine-serverso embedded-mode users don't need a separate dependency.Type:
Why Is This Needed?
#320 —
saturating_duration_sincein learner promotionInstant::duration_sincepanics in debug mode if the argument is laterthan
self(can occur under VM snapshots or certain NTP adjustments).Replaced with
saturating_duration_sinceat all three call sites in thestale-learner cleanup path, returning
Duration::ZEROinstead of panicking.#323 — expose
ClientApiin embedded modeEmbeddedClientimplementsClientApi, butClientApiitself was notre-exported from
d-engine-server. Embedded-mode users who wanted to useClientApias a trait bound in their own code had to addd-engine-clientas a separate dependency — pulling in the full gRPC client crate just to
access a trait definition. Fixed by re-exporting
ClientApi,ClientApiError,and
ClientApiResultdirectly fromd-engine-server.Checklist
Required:
make testpassesIf changing APIs:
Testing
How tested:
-p d-engine-core learner)d-engine-servercompiles cleanly with new re-exportsFor bug fixes:
(Both fixes are defensive; the panic in fix: replace Instant::duration_since with saturating_duration_since in learner promotion logic #320 requires specific clock
conditions to reproduce, and fix: ClientApi trait not exposed in embedded mode without client feature #323 is a compilation error by nature)
Does This Follow d-engine's Principles?
Reviewer Notes
Two unrelated fixes bundled to avoid two separate CI runs. Each commit
is self-contained and can be reviewed independently.
Estimated review complexity:
Summary by CodeRabbit
Bug Fixes
New Features