Skip to content

fix: skip ISDLOCK inv announcements for peers requesting recsigs#6994

Merged
PastaPastaPasta merged 1 commit intodashpay:developfrom
PastaPastaPasta:feat/no-send-isdlock-on-recsig
Nov 21, 2025
Merged

fix: skip ISDLOCK inv announcements for peers requesting recsigs#6994
PastaPastaPasta merged 1 commit intodashpay:developfrom
PastaPastaPasta:feat/no-send-isdlock-on-recsig

Conversation

@PastaPastaPasta
Copy link
Copy Markdown
Member

Issue being fixed or feature implemented

Masternode to masternode connections which share recovered signatures, should not share isdlocks; as these are higher level messages produced for users /consumers, which these masternodes can reconstruct from the recsig. To avoid wasted bandwidth and processing, we should skip sending isdlock invs to peers that we send recSigs to.

What was done?

Don't send inv for isdlocks for peers who request recsigs.

How Has This Been Tested?

Breaking Changes

None

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

@PastaPastaPasta PastaPastaPasta added this to the 23.1 milestone Nov 19, 2025
@github-actions
Copy link
Copy Markdown

✅ No Merge Conflicts Detected

This PR currently has no conflicts with other open PRs.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Nov 19, 2025

Walkthrough

The changes modify inventory propagation logic in the peer-to-peer message handling to conditionally skip ISDLOCK announcements for peers that request recovery signatures (recsigs). In PushInv, ISDLOCK announcements are now filtered for recsig-requesting peers. In SendMessages, a guard condition was added to prevent enqueuing ISDLOCK inventory when a peer requests recsigs. This optimization reduces unnecessary ISDLOCK traffic to peers capable of reconstructing islocks from recsigs.

Sequence Diagram(s)

sequenceDiagram
    participant Node
    participant PushInv
    participant SendMessages
    participant Peer

    Node->>SendMessages: Process outgoing inventory
    SendMessages->>SendMessages: Check: Does peer want recsigs?
    alt Peer wants recsigs
        SendMessages->>SendMessages: Skip ISDLOCK inv
        Note over SendMessages: Guard prevents enqueue
    else Peer does not want recsigs
        SendMessages->>PushInv: Add to inventory queue
        PushInv->>Peer: Send ISDLOCK announcement
    end
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Localized changes to two functions within a single file
  • Conditional guard logic is straightforward (checking peer recsig preference)
  • Verify that the guard condition is correctly placed and doesn't inadvertently skip other inventory types
  • Confirm peer state queries (wantRecsigs) are reliable and consistent with peer capability tracking

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically summarizes the main change: skipping ISDLOCK inventory announcements for peers that request recovered signatures, which directly matches the core objective of the changeset.
Description check ✅ Passed The description is directly related to the changeset, explaining the issue, the solution implemented, and the rationale for the optimization regarding ISDLOCK propagation to peers requesting recsigs.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 86e84d7 and 99e7997.

📒 Files selected for processing (1)
  • src/net_processing.cpp (2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: kwvg
Repo: dashpay/dash PR: 6761
File: src/chainlock/signing.cpp:247-250
Timestamp: 2025-07-29T14:32:48.369Z
Learning: In PR #6761, kwvg acknowledged a null pointer check issue in ChainLockSigner::Cleanup() method but deferred it to follow-up, consistent with the pattern of avoiding scope creep in refactoring PRs.
Learnt from: kwvg
Repo: dashpay/dash PR: 6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.
📚 Learning: 2025-09-09T21:36:11.833Z
Learnt from: kwvg
Repo: dashpay/dash PR: 6837
File: src/stats/rawsender.cpp:0-0
Timestamp: 2025-09-09T21:36:11.833Z
Learning: In RawSender class (src/stats/rawsender.cpp), cs_net is the appropriate mutex for protecting socket access (m_sock) and network operations, not additional custom locks. The implementation correctly uses cs_net with GUARDED_BY annotations and EXCLUSIVE_LOCKS_REQUIRED to synchronize socket access between SendDirectly() and ReconnectThread().

Applied to files:

  • src/net_processing.cpp
🧬 Code graph analysis (1)
src/net_processing.cpp (3)
src/instantsend/net_instantsend.cpp (1)
  • inv (189-189)
src/protocol.h (1)
  • CInv (531-568)
src/protocol.cpp (2)
  • CInv (263-267)
  • CInv (269-269)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
  • GitHub Check: linux64_ubsan-build / Build source
  • GitHub Check: linux64_sqlite-build / Build source
  • GitHub Check: linux64-build / Build source
  • GitHub Check: linux64_fuzz-build / Build source
  • GitHub Check: arm-linux-build / Build source
  • GitHub Check: mac-build / Build source
  • GitHub Check: win64-build / Build source
  • GitHub Check: linux64_tsan-build / Build source
  • GitHub Check: linux64_nowallet-build / Build source
  • GitHub Check: Lint / Run linters
🔇 Additional comments (2)
src/net_processing.cpp (2)

1191-1197: ISDLOCK inv skip for recsig peers in PushInv is correct and safe

The early return for MSG_ISDLOCK when peer.m_wants_recsigs is set cleanly prevents queuing redundant ISDLOCK inventory for peers that can reconstruct locks from recsigs, and uses the atomic flag without introducing new locking or control‑flow issues.


6269-6272: Mempool ISDLOCK inv suppression is consistent with recsig semantics

Conditioning the MSG_ISDLOCK mempool announcement on !peer->m_wants_recsigs brings the BIP35 mempool response path in line with the new PushInv behavior, so recsig‑requesting peers no longer get duplicate ISDLOCK invs while others still do.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 99e7997

Copy link
Copy Markdown
Collaborator

@kwvg kwvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 99e7997

@PastaPastaPasta PastaPastaPasta merged commit 5dca160 into dashpay:develop Nov 21, 2025
53 of 60 checks passed
knst added a commit to knst/dash that referenced this pull request Apr 26, 2026
PR dashpay#6994 stopped sending ISDLOCK invs to peers requesting recsigs on the premise
that they can reconstruct the islock from the recsig. That reconstruction has
a pre-existing race that become critical now.
It causes intermittent failure in interface_zmq_dash.py - wait_for_instantlock
timing out.

The previous reconstruction path checked HasRecoveredSigForId before
emplacing into creatingInstantSendLocks, which leaves a window:

thread A: ProcessRecoveredSig writes recsig to db, listener fires
          HandleNewRecoveredSig, finds creating empty, no-ops
thread B: TrySignInstantSendLock saw HasRecoveredSigForId=false,
          now emplaces and calls AsyncSignIfMember

It causes recsig to be in in db but no one ever builds the islock:
 - db.HasRecoveredSigForHash blocks any subsequent listener firing for
that recsig
 - TrySignInstantSendLock has already passed its check

Before dashpay#6994 this was masked because the peer would still receive the ISDLOCK inv from another node,
but on develop the peer no longer receives an ISDLOCK inv from peers as a fallback.

Reorder to emplace first, then check:

1. Emplace into creatingInstantSendLocks. Any listener that fires
 after this point sees the entry and reconstructs via the existing
 HandleNewInstantSendLockRecoveredSig path.
2. Then check HasRecoveredSigForId. If already in db, find+erase the
 entry; if find misses, the listener already handled it.
3. Only call AsyncSignIfMember when no recsig exists yet.
PastaPastaPasta pushed a commit that referenced this pull request Apr 28, 2026
PR #6994 made masternodes skip ISDLOCK inv announcements to any peer with
m_wants_recsigs set, on the premise that such peers can reconstruct the ISLOCK
from the recsig.

It works for MN peers but it does not work for quorum observers running with
-watchquorums: those nodes also opt in to recsigs via QSENDRECSIGS but they
don't have a signer worker running, so they cannot reconstruct an ISDLOCK from
a recsig and they still need the inv.

nodes[0] runs with -watchquorums and had progressively sent QSENDRECSIGS to all
four MN peers; by the third call every MN saw nodes[0].m_wants_recsigs=true and
skipped the inv to it.

This commit make the ISDLOCK skipped only on the peer being verified masternode.
Move the policy from PushInv (called for every inv type) to the three sites that
actually relay MSG_ISDLOCK and have CNode in scope.
PastaPastaPasta added a commit that referenced this pull request Apr 28, 2026
…hquorums

f6bb02d fix: keep sending ISDLOCK invs to non-MN peers that want recsigs (Konstantin Akimov)

Pull request description:

  ## Issue being fixed or feature implemented

  PR #6994 made masternodes skip ISDLOCK inv announcements to any peer with m_wants_recsigs set, on the premise that such peers can reconstruct the ISLOCK from the recsig.

  It works for MN peers but it does not work for quorum observers running with -watchquorums: those nodes also opt in to recsigs via QSENDRECSIGS but they don't have a signer worker running, so they cannot reconstruct an ISDLOCK from a recsig and they still need the inv.

  nodes[0] runs with -watchquorums and had progressively sent QSENDRECSIGS to all four MN peers; by the third call every MN saw nodes[0].m_wants_recsigs=true and skipped the inv to it.

  ## What was done?
  The ISDLOCK is skipped now only on the peer being verified masternode. Move the policy from PushInv (called for every inv type) to the three sites that actually relay MSG_ISDLOCK and have CNode in scope.

  ## How Has This Been Tested?
  Run functional test interface_dash_zmq.py multiple times.
  This PR drops failure rate from 50% to 0.

  ## Breaking Changes
  N/A

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [ ] I have commented my code, particularly in hard-to-understand areas
  - [ ] I have added or updated relevant unit/integration/functional/e2e tests
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone

ACKs for top commit:
  PastaPastaPasta:
    utACK f6bb02d

Tree-SHA512: 14be2cfaad6dd0cb359bedca9e65e176b3d52de109f1c9e606892ee284f8079860d01117d538efb19bcf695e5da0cae747f08dcb98c209624ca28d6cf7d1e34d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants