fix: forward subscription updates that resolve pending fetches - #1508
Conversation
An update consumed to resolve a pending fetch was not forwarded to the update pipeline, and submux dedup has already dropped every other copy. Correctness then depended on the fetch caller cloning the result, which non-cloning callers (delegation-status reads) and failing multi-stage resolutions do not: the freshest state was lost and, with a stale copy in the bank suppressing refetches, the account stayed wedged until the next on-chain write. Consumption is now non-exclusive: the update resolves the waiters and is forwarded like any other notification. Double-processing is benign via the existing non-advancing-slot gate.
|
Warning Review limit reached
Next review available in: 53 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. 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, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughSubscription updates that resolve in-flight account fetches are now forwarded into the main update pipeline while also resolving fetch waiters. Tests now verify forwarded redelegation and consumed updates, validate subscription-derived fetch results and forwarding, and use lower-bound assertions for shared companion-fetch attempt metrics. Suggested reviewers: ✨ 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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b8bd5ca3a9
ℹ️ 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".
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@magicblock-chainlink/src/remote_account_provider/tests.rs`:
- Around line 1663-1669: Update the paired histogram-sum assertion following
chainlink_companion_fetch_attempts_sample_count to require at least
attempts_sum_before + 1.0 instead of exactly that value, preserving
concurrency-safe behavior when same-label observations increase the sum.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 2200d86a-924e-448a-88a9-9fa1c2c104eb
📒 Files selected for processing (3)
magicblock-chainlink/src/chainlink/fetch_cloner/tests.rsmagicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/remote_account_provider/tests.rs
Problem
A subscription update arriving for an account with a fetch in flight is consumed to resolve that fetch and never forwarded to the update pipeline — while submux dedup has already dropped every other copy. Correctness silently depends on the fetch caller cloning the result. Non-cloning callers (delegation-status reads via
fetch_remote_accounts) and multi-stage resolutions that fail mid-churn discard it, permanently losing the freshest chain state. With a stale copy in the bank suppressing refetches, the account stays wedged until the next on-chain write — reproducible by delegating/undelegating in quick succession while anything polls the account.#1507 fixed one consumer of this class (the slot-matching companion path); this fixes the class at its source.
Solution
Consumption is non-exclusive: the update resolves the fetch waiters and is forwarded like any other notification (one
None→Some(update)at the arbitration site). Double-processing is benign via the existing non-advancing-slot gate.Tests
test_update_resolving_pending_fetch_is_also_forwarded— non-cloning fetch in flight, update consumed; red before, green after.Summary by CodeRabbit
Bug Fixes
Tests