Net: Interrupt orphan transaction processing

[navidR]

Process at most one expensive orphan transaction attempt per scheduling cycle. This prevents a newly accepted parent from causing a long uninterrupted validation stall while preserving orphan processing across later cycles.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[reubenyap]

@CodeAnt-AI review

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	b829713	Aug 29, 2026 · 08:26	08:30

[codeant-ai]

User description

Process at most one expensive orphan transaction attempt per scheduling cycle. This prevents a newly accepted parent from causing a long uninterrupted validation stall while preserving orphan processing across later cycles.

---

CodeAnt-AI Description

Interrupt orphan transaction processing to keep network message handling responsive

What Changed

• Processes at most one orphan transaction attempt per message-processing cycle
• Continues pending orphan processing in later cycles instead of blocking while validating a long dependency chain
• Preserves orphan promotion, removal, peer penalties, relay, and compact transaction handling across interrupted cycles
• Adds coverage confirming orphan work is deferred without losing pending transactions

Impact

✅ Fewer network message processing stalls
✅ Responsive handling of newly accepted parent transactions
✅ Reliable orphan transaction processing across cycles

💡 Usage Guide

Checking Your Pull Request

Every 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 AI

Got 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:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You 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:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To 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.

[codeant-ai]

Suggestion: Accepted orphans do not refresh the sending peer's nLastTXTime, unlike the normal transaction path. Because fromPeer is stored with the orphan, the peer that supplied the orphan can remain indistinguishable from an inactive peer and become incorrectly favored for eviction. Update the originating peer's transaction timestamp when the orphan is accepted. [state lifecycle]

Severity Level: Major ⚠️

- ⚠️ Orphan-originating peers retain stale transaction timestamps.
- ⚠️ Inbound eviction can favor stale peers incorrectly.
- ⚠️ Active orphan contributors may be disconnected under connection pressure.

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/net_processing.cpp
**Line:** 1385:1385
**Comment:**
	*State Lifecycle: Accepted orphans do not refresh the sending peer's `nLastTXTime`, unlike the normal transaction path. Because `fromPeer` is stored with the orphan, the peer that supplied the orphan can remain indistinguishable from an inactive peer and become incorrectly favored for eviction. Update the originating peer's transaction timestamp when the orphan is accepted.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[codeant-ai]

Suggestion: Dependent orphan hashes are queued only on the peer currently processing the accepted parent, even though each orphan retains its own fromPeer. If that processing peer disconnects before its next scheduling cycle, the queue is destroyed while the dependent orphan remains in mapOrphanTransactions, so it is never retried unless the parent is accepted again. [stale reference]

Severity Level: Major ⚠️

- ⚠️ Cross-peer orphan chains may stop processing.
- ❌ Valid dependent transactions can remain orphaned.
- ⚠️ Orphan entries persist until expiry or eviction.

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/net_processing.cpp
**Line:** 1389:1391
**Comment:**
	*Stale Reference: Dependent orphan hashes are queued only on the peer currently processing the accepted parent, even though each orphan retains its own `fromPeer`. If that processing peer disconnects before its next scheduling cycle, the queue is destroyed while the dependent orphan remains in `mapOrphanTransactions`, so it is never retried unless the parent is accepted again.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[reubenyap]

I found two actionable lifecycle regressions in the deferred work:

• src/net_processing.cpp:2293: the remaining orphan IDs are stored on the peer that delivered the parent. If peer A supplied two children missing parent P and peer B supplies P, one child is attempted immediately and the other exists only in B’s orphan_work_set. If B disconnects before its next message-handler pass, CNode destruction drops that set; A’s orphan remains in the global orphan map, but P is already accepted and no path schedules it again. Please keep deferred orphan work in net-processing state independent of the parent peer’s lifetime (or explicitly transfer it during teardown).
• src/net_processing.cpp:1343: setMisbehaving is recreated on every helper call, while line 1367 deliberately stops after one live orphan. It therefore never suppresses a second penalty, unlike the old single-batch loop: successive deferred invalid orphans from one source can each add DoS score across passes. Please persist the punished-source state across the sliced batch, or otherwise retain the previous one-penalty-per-source behavior.

The existing test exercises two passes on a live node, so neither disconnect nor repeated-source case is covered.