LLMQ: bound locked transaction requests - #1938
Conversation
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used all 4 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: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
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. |
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
User descriptionLimit locked-transaction requests to four suitable peers and use the correct inventory mutex. Add focused coverage for peer selection, masternode preference, and cleanup. CodeAnt-AI DescriptionBound InstantSend requests and prioritize masternode peers What Changed
Impact
💡 Usage GuideChecking Your Pull RequestEvery time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later. Talking to CodeAnt AIGot a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask: This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code. ExamplePreserve Org Learnings with CodeAntYou can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input: This helps CodeAnt AI learn and adapt to your team's coding style and standards. ExampleRetrigger reviewAsk CodeAnt AI to review the PR again, by typing: Check Your Repository HealthTo analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9eac7ce259
ℹ️ 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".
| pnode->AddRef(); | ||
| nodesToAskFor.emplace_back(pnode); |
There was a problem hiding this comment.
Count only peers that accept the request
When any of the first four candidates has an over-limit vecAskFor or setAskFor—for example, after an inventory flood—CNode::AskFor returns without queuing anything (src/net.cpp:3568-3579), but this peer has already consumed one of the four vector slots. Since subsequent eligible peers are skipped once the vector reaches four, recovery can enqueue fewer than four, or even zero, requests and never ask an available fifth peer for the locked transaction; continue selecting until four requests are actually accepted.
AGENTS.md reference: AGENTS.md:L238-L238
Useful? React with 👍 / 👎.
reubenyap
left a comment
There was a problem hiding this comment.
Reviewed peer selection end to end, including connection lifetime/ref-counting, the inventory lock, masternode-first ordering, request cleanup, and the focused boundary test. The four-peer cap is enforced without dropping the preferred eligible peers; CI is green, and I found no new actionable defects.
Limit locked-transaction requests to four suitable peers and use the correct inventory mutex. Add focused coverage for peer selection, masternode preference, and cleanup.
Upstream: Dash PR #4680 and Dash PR #4203.