[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

For a GetBlock with requestShortCircuitAccess set, KeyValueHandler.handleGetBlock opens the block file, parks it in blockFileMap under a key built from request fields (clientId, callId, local ID, container ID) and sets shortCircuitAccessGranted in the response. The handler does this for any GetBlock that carries the flag, because it does not know which path dispatched the request, and the map is shared by all requests. Only the domain socket Receiver takes the file out again (through Handler.getBlockFile) and closes it after sending the descriptor. So:

• A GetBlock with the flag dispatched by another path (GrpcXceiverService, ContainerStateMachine.query) parks a file that nothing takes out, and its response reports shortCircuitAccessGranted=true although that path passes no descriptor.
• Requests with the same key share one entry: a later put replaces an earlier file without closing it, and the Receiver task that looks second finds no entry.

This change hands the opened file to the request's own context instead of a shared map. Receiver dispatches each request with its own DispatcherContext of a new op, HANDLE_SHORT_CIRCUIT_READ; handleGetBlock opens the file only for such a context and stores it there, and Receiver takes it from that context. A GetBlock with the flag dispatched without that context gets the block data and shortCircuitAccessGranted=false, which the read path already treats as "read normally". blockFileMap, KeyValueHandler.getBlockFile and the abstract Handler.getBlockFile are removed. The block token is still verified for the new op, and there is no wire or protocol change.

Overlap with other open changes: this and HDDS-17443 change adjacent lines in Receiver.ProcessRequestTask.run; whichever lands second needs a trivial rebase.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-17445

How was this patch tested?

• New TestKeyValueHandler.testShortCircuitGetBlockHandsFileToOwnContext: a GetBlock with the flag dispatched without the domain socket context gets shortCircuitAccessGranted=false and counts no local bytes, a domain socket context without the flag gets no file, and two dispatches of the same request with their own contexts each get their own open file. Without the change the first part fails with "Expecting value to be false but was true".
• TestKeyValueHandler, TestKeyValueHandlerWithUnhealthyContainer and TestHddsDispatcher (129 tests), and TestXceiverServerDomainSocket, TestXceiverClientManagerSC, TestLocalChunkInputStream and TestDomainSocketFactory pass locally on macOS; checkstyle is clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[ChenSammi]

@smengcl , thanks for the change. Overall it looks good to me.

"A GetBlock with the flag from GRPC" is possible under an attacker's case, but "Requests with the same key share one entry" seems not easy even for an attacker if it's not DN service which is been compromised.