bryancall opened a new pull request, #13833: URL: https://github.com/apache/trafficserver/pull/13833
The two client RST_STREAM cases in `http2_rst_stream` check that the origin never logs `RST_STREAM`. That only holds when the client's reset reaches ATS before ATS has finished its TLS handshake with the origin, which is the usual order. On a busy CI machine the client can be paused between frames, and then ATS forwards the request first. The origin answers, the client is already gone, ATS closes the origin stream, and when the origin's DATA arrives on that closed stream ATS answers it with `RST_STREAM(NO_ERROR)` from the outbound branch of `Http2ConnectionState::rcv_data_frame`. By then the origin has sent its whole response and closed the stream, so it is not affected, but the check fails. This has been failing autest shard 1of4 on PRs that do not touch HTTP/2, for example [#13818](https://github.com/apache/trafficserver/pull/13818) and [#13424](https://github.com/apache/trafficserver/pull/13424). This changes the check to fail only when an `RST_STREAM` reaches the origin while its stream is still open, which is what a client abort leaking through to the origin would look like. Testing: in the `ci.trafficserver.apache.org/ats/fedora:44` image, with 32 copies of the test running in parallel and CPU load on the host, master failed 84 of 1280 runs on one machine and 85 of 1280 on a second, every time on this check. This change failed 0 of 1280 on each under the same load, although the origin saw the forwarded request in 97 and 112 of those runs. To make sure the new check still catches the real problem, I built ATS with the outbound exemption in `Http2Stream::do_io_close` removed, so a client abort resets the origin stream, and delayed the client's reset so ATS reaches the origin first. The new check failed on that build in all 6 runs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
