Dispatch snap server request processing off Netty event loop

[macfarla]

SnapProtocolManager.processMessage() was calling snapMessages.dispatch() synchronously on the Netty event loop thread for incoming GET_* snap requests. These handlers do heavy work (trie traversal, proof generation, DB reads) that can take several seconds, blocking the event loop and preventing the server from responding to concurrent ETH protocol messages such as GET_BLOCK_HEADERS.

When testing with besu server <> besu client, this caused the client to accumulate 5+ (eth,3) timeouts and disconnect the server with TIMEOUT.

Fix: for even-coded snap request messages (GET_ACCOUNT_RANGE, GET_STORAGE_RANGE, GET_BYTECODES, GET_TRIE_NODES), dispatch the heavy snapMessages.dispatch() work and the subsequent send() to EthScheduler's service thread pool. The Netty event loop now returns immediately after dispatching, staying free to handle ETH messages. Response messages (odd codes) are already handled by dispatchMessage() and need no changes.

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[Copilot]

Pull request overview

Dispatches inbound SNAP GET_* request handling off the Netty event loop to avoid blocking ETH protocol processing and timeouts.

Changes:

• Add EthScheduler to SnapProtocolManager and wire it from BesuControllerBuilder.
• Offload even-coded SNAP request processing (GET_*) to EthScheduler service threads, including response sending.
• Adjust malformed SNAP message handling to ignore malformed request payloads instead of disconnecting.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapProtocolManager.java	Offloads SNAP GET_* request dispatch + response send to service thread pool via EthScheduler.
app/src/main/java/org/hyperledger/besu/controller/BesuControllerBuilder.java	Wires EthScheduler into SnapProtocolManager construction.

[pinges]

Code review

Found 2 issues:

1. SnapV1.REQUEST_CODES only contains snap/1 request codes {0x00, 0x02, 0x04, 0x06}, but SnapProtocolManager also handles snap/2 via SNAP2 capability. PR EIP-8189: snap/2 #10064 (merged just before this PR) added SnapV2.GET_BLOCK_ACCESS_LISTS = 0x08. Since 0x08 is not in SnapV1.REQUEST_CODES, when a snap/2 peer sends a GET_BLOCK_ACCESS_LISTS request, scheduleSnapRequest is never called and the request is silently dropped -- breaking snap/2 server-side functionality entirely.

besu/ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/messages/snap/SnapV1.java

Lines 30 to 33 in 5e521e8

	/** The set of inbound request message codes that the snap server must handle. */
	public static final Set<Integer> REQUEST_CODES =
	Set.of(GET_ACCOUNT_RANGE, GET_STORAGE_RANGE, GET_BYTECODES, GET_TRIE_NODES);

besu/ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapProtocolManager.java

Lines 143 to 146 in 5e521e8

	// GET_* requests are handled off the Netty event loop to avoid blocking ETH protocol traffic.
	if (SnapV1.REQUEST_CODES.contains(code)) {
	scheduleSnapRequest(ethPeer, decodedEthMessage, cap, code);
	}

2. scheduleServiceTask(Runnable) returns a CompletableFuture<Void> that is silently discarded. Unlike the EthTask overload, the Runnable overload does not add the future to pendingFutures, so: (a) any non-RLPException RuntimeException thrown inside the lambda is silently swallowed, and (b) during node shutdown, in-flight snap request tasks are not cancelled via pendingFutures and may continue executing against partially torn-down state. Consider using the EthTask overload, or at minimum attaching an exceptionally handler to log unexpected failures.

besu/ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapProtocolManager.java

Lines 148 to 172 in 5e521e8

	private void scheduleSnapRequest(
	final EthPeer ethPeer,
	final EthMessage decodedEthMessage,
	final Capability cap,
	final int code) {
	ethScheduler.scheduleServiceTask(
	() -> {
	Optional<MessageData> maybeResponseData = Optional.empty();
	try {
	final Map.Entry<BigInteger, MessageData> requestIdAndEthMessage =
	decodedEthMessage.getData().unwrapMessageData();
	maybeResponseData =
	snapMessages
	.dispatch(new EthMessage(ethPeer, requestIdAndEthMessage.getValue()), cap)
	.map(
	responseData ->
	responseData.wrapMessageData(requestIdAndEthMessage.getKey()));
	} catch (final RLPException e) {
	LOG.debug(
	"Received malformed snap message code={} (BREACH_OF_PROTOCOL), disconnecting: {}",
	code,
	ethPeer,
	e);
	ethPeer.disconnect(DisconnectReason.BREACH_OF_PROTOCOL_MALFORMED_MESSAGE_RECEIVED);

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[pinges]

Please catch FramingException as well. See comment.

[pinges]

LGTM