[SPARK-57709][CORE] Fail the stream callback and close the channel when installing the stream interceptor fails#56802
Open
LuciferYang wants to merge 1 commit into
Open
Conversation
…en installing the stream interceptor fails When installing the stream interceptor fails in TransportResponseHandler (the frame decoder is missing from the pipeline, or setInterceptor throws), the StreamResponse branch previously logged and only called deactivateStream(). The StreamCallback had already been removed from the queue, so it was never failed and the caller would block until the connection idle-timeout. Fail the callback, consistent with every other branch in handle(), and close the channel since its framing can no longer be relied on. This is defensive hardening: the path is effectively unreachable under normal operation, because framing is suspended while an interceptor is active and the frame decoder is not removed mid-dispatch on the channel event loop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
In
TransportResponseHandler, when aStreamResponsearrives and installing the stream interceptor fails (theTransportFrameDecoderis missing from the channel pipeline, orsetInterceptorthrows), the handler now fails the stream callback and closes the channel. Previously it only logged the error and calleddeactivateStream(), leaving theStreamCallback, which had already been removed from the queue, without any completion or failure notification.Why are the changes needed?
This is defensive hardening rather than a fix for a failure seen in practice. The catch block is effectively unreachable in normal operation: while an interceptor is active the frame decoder stops framing, so the
setInterceptorstate check cannot trip, and the decoder is not removed mid-dispatch on the single channel event loop. Even so, every other branch inhandle()notifies its callback while this one did not, so if the path were ever reached the caller would block until the connection idle-timeout instead of failing cleanly. Closing the channel also keeps a connection whose framing can no longer be trusted out of the pool, where it could otherwise corrupt later requests.Does this PR introduce any user-facing change?
No.
How was this patch tested?
Added
TransportResponseHandlerSuite.failStreamCallbackWhenInstallingInterceptorFails, which handles aStreamResponseon a channel whose pipeline has noTransportFrameDecoder, so installing the interceptor throws. It verifies that the callback is failed with the install exception and that the channel is closed. The test fails on the old code (the callback receives no interaction) and passes with the fix; the fullTransportResponseHandlerSuitepasses.Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 4.8)