Fix delegated roll result synchronization - #120
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughChangesDelegated Roll Flow
Estimated code review effort: 4 (Complex) | ~60 minutes Suggested reviewers: ✨ 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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 97fd2ec07d
ℹ️ 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".
| } | ||
| return | ||
| } | ||
| if (slot <= requestSlot) return |
There was a problem hiding this comment.
Accept the request transaction's account update
When rollnum has saturated at 255, the account write produced by this roll is in the same Solana slot as the tracked signature, so its account-change callback has slot === requestSlot. This <= check discards that actual result; the deferred path also only replays a notification whose slot is greater. Consequently every roll after the counter reaches 255 remains pending indefinitely (until an unrelated later account write), despite the transaction succeeding.
Useful? React with 👍 / 👎.
Summary
u8roll counter reaches 255Summary by CodeRabbit