fix: retry forester epoch processing failures - #2388
Conversation
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced 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 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3ed45606c4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| error = ?error, | ||
| "Epoch processing failed; retrying" | ||
| ); | ||
| sleep(retry_delay).await; |
There was a problem hiding this comment.
Bound the backoff by the report-work deadline
When an attempt fails with less than retry_delay remaining in the report-work phase—for example, a transient report_work_onchain failure—the unconditional sleep can carry the task past phases.report_work.end. The subsequent process_epoch call then skips the on-chain report and returns Ok(()), so the retry loop logs recovery even though has_reported_work remains false and the epoch's work is omitted from total_work. Cap the sleep to the remaining phase time or otherwise prevent a post-deadline attempt from being treated as successful.
Useful? React with 👍 / 👎.
Summary
Root cause
The epoch monitor emits each epoch once. If
process_epochfailed during that one attempt—for example, when the RPC provider returned HTTP 500—the spawned task exited and the forester never built that epoch's schedule. Processing remained stuck until the process was restarted.Impact
Foresters now recover automatically from transient failures during epoch setup instead of silently remaining inactive for the rest of the epoch. Retry tasks are bounded by the report-work deadline.
Validation
cargo test -p forester test_epoch_processing_retry_delay_is_exponential_and_capped --libcargo check -p forestergit diff --check