fix(txsubmission): handle client MsgDone in server agent to avoid mempool stall

[nemo83]

Problem

The N2N TxSubmission server agent never handled a client MsgDone. When a peer
terminates the tx-submission mini-protocol with MsgDone while the server is
blocking-waiting in TxIdsBlocking, the state machine dropped it on the floor:

• TxSubmissionState.TxIdsBlocking.nextState() only transitioned on ReplyTxIds, so
  MsgDone returned this → the agent stayed wedged in TxIdsBlocking forever.
• In TxIdsBlocking the client holds agency, so the server can never send another
  RequestTxIds → repeated WARN Cannot request tx IDs in state: TxIdsBlocking.
• Because the agent never becomes Done, MiniProtoServerInboundHandler keeps it
  registered and later logs No agent found to handle protocol ....
• TxSubmissionServerAgent.processResponse() had no MsgDone branch, so it also logged
  WARN Unexpected message type: MsgDone.

Net effect: the node silently stops ingesting mempool transactions while
chain-sync and block-fetch keep working normally. Observed in production: the mempool
feed went dead and never recovered until the process was restarted.

Fix

• TxSubmissionState: transition to Done on MsgDone from the client-agency states —
  TxIdsBlocking (per the node-to-node tx-submission spec), plus TxIdsNonBlocking and
  Txs defensively.
• TxSubmissionServerAgent.processResponse: handle MsgDone explicitly (clear in-flight
  bookkeeping, log at INFO) instead of falling through to Unexpected message type.

Once the agent reaches Done, the inbound handler stops routing to it and a fresh agent
is created when the peer reconnects — restoring mempool ingestion automatically.

Tests

Adds unit tests to TxSubmissionServerAgentTest:

• testMsgDoneFromTxIdsBlockingTransitionsToDone — drives the agent into TxIdsBlocking,
  sends MsgDone, asserts it reaches Done / isDone().
• testMsgDoneStateTransitionsForAllClientAgencyStates — asserts the MsgDone → Done
  transition for TxIdsBlocking, TxIdsNonBlocking, and Txs.

Full suite for the class passes (15 tests, 0 failures).

Scope / risk

Low and localized (2 main-source files). It only adds handling for a legal protocol
message that was previously dropped; the happy path is unchanged.

[satran004]

Looks good. Just a minor comment in State class.

[satran004]

@nemo83 Should we exclude this state transition as it is not part of the spec? So ideally it should never reach to this point.

[nemo83]

Good call — agreed. Removed this transition; MsgDone is only legal in TxIdsBlocking per the spec, so TxIdsNonBlocking now just ignores it and stays put. Pushed in 53eea24.

[satran004]

Same as before.

[nemo83]

Same here — removed the defensive MsgDone transition from Txs as well.

[beanbot-gh]

Review — handle client MsgDone in TxSubmission server agent

Summary: Fixes a real production stall where an N2N peer sending MsgDone while the server is blocking in TxIdsBlocking wedged the agent forever (client holds agency there, so the server could never send another RequestTxIds), silently killing mempool ingestion. The fix adds MsgDone → Done transitions for the three client-agency states and an explicit handleDone() that clears in-flight bookkeeping. Diagnosis and fix both look correct — LGTM. 👍

Verified

• End-to-end decode path works (the bit the unit tests don't cover). The tests drive receiveResponse(new MsgDone()) directly, bypassing decoding. I checked TxSubmissionStateBase.handleInbound(...): it decodes by CBOR message id independent of state, and MsgDone is id 4 → MsgDoneSerializer. So a real MsgDone on the wire in TxIdsBlocking is decoded to a MsgDone and then hits the new nextState branch. The fix isn't just unit-green, it works against actual traffic.
• State choice matches the protocol. MsgDone is only legal where the client has agency — TxIdsBlocking / TxIdsNonBlocking / Txs. Leaving Idle (server agency) untouched is correct; the client can't send MsgDone there. Done is terminal (nextState returns this, hasAgency false).
• handleDone() is safe. outstandingTxIds (ConcurrentLinkedQueue) and pendingRequest (volatile) both exist; clearing them prevents leaked bookkeeping. isDone() returns currentState == Done, so the inbound handler stops routing after this. MsgDone resolves via the existing wildcard import — compiles cleanly.
• Since state advances in Agent.receiveResponse before processResponse runs, handleDone() observes currentState == Done, consistent with the javadoc.

Optional (non-blocking)

• handleDone() clears outstandingTxIds + pendingRequest, which overlaps with the cleanup already in shutdown()/reset. Not worth a shared helper here — inline is clearer — just noting the duplication in case it grows.

Nice catch on a nasty silent-failure bug, and the PR description's root-cause writeup is excellent.

[nemo83]

Updated per @satran004's review (53eea24).

Removed the two defensive MsgDone → Done transitions from TxIdsNonBlocking and Txs. As noted, MsgDone is only legal in TxIdsBlocking under the node-to-node tx-submission spec, so those states can never legitimately reach that point — they now simply ignore MsgDone and stay put. Only the spec-mandated TxIdsBlocking transition remains.

Updated testMsgDoneStateTransitionsForAllClientAgencyStates → testMsgDoneStateTransition to assert TxIdsBlocking → Done while TxIdsNonBlocking/Txs remain unchanged on MsgDone.

As a side effect this also removes the duplicated branches that tripped the SonarQube "duplication on new code" gate.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud