Handle header with errors and endStream = true #10384
Conversation
…operty for streamKey (header processing identified an error).
| @@ -679,12 +685,14 @@ void returnProcessedBytes(Http2Stream http2Stream, int bytes) { | |||
|
|
|||
| private void closeStreamWhenDone(ChannelPromise promise, int streamId) throws Http2Exception { | |||
There was a problem hiding this comment.
Hmm... All callers to this method have the TransportState, but it is hidden behind the StreamIdHolder interface. In the future we should probably just have the callers pass the object in, but that'd require some changes to the commands.
There was a problem hiding this comment.
That would break encapsulation. Since the public method is using StreamIdHolder we would have to check if the type was TransportState and have alternate logic based upon whether it was or not which might be more efficient, but would also be more complicated.
There was a problem hiding this comment.
No, we'd just expose TransportState directly from the commands. The commands are just for Netty*Stream and Netty*Handler to communicate.
…axage (unless maxAge is < 2 minutes) for the RLS configuration from proto.
…r than maxage (unless maxAge is < 2 minutes) for the RLS configuration from proto." This reverts commit aa87130.
larry-safran
added
the
TODO:backport
* Eliminate NPE by skipping further processing when stream is defined, but doesn't have a property for streamKey (header processing identified an error) Fixes grpc#10364 * Add unit test for missing content type
larry-safran
removed
the
TODO:backport
We catch a number of errors in onHeadersRead where we return an error to the caller and then return without completing any more logic. When endStream is true, onDataRead which is dependent on values set at the end of the onHeadersRead method which was leading to NPEs.
Fixes #10364