Fix HTTP/2 stream (transaction) inactivity timeout

[masaori335]

Prior to the change, the activity of the Http2Stream was updated even if send_a_data_frame is failed by error like NO_WINDOW which breaks inactivity timeout.

It looks like when a write is success, the activity is updated by Http2Stream::signal_write_event, so Http2Stream::send_body don't need to update it.

trafficserver/src/proxy/http2/Http2Stream.cc

Line 950 in 83ec495

_timeout.update_inactivity();

[Copilot]

Pull request overview

Fixes HTTP/2 stream inactivity timeout behavior by avoiding “activity” updates when DATA frame transmission fails due to flow-control conditions (e.g., NO_WINDOW), which previously could prevent transaction_no_activity_timeout_in from firing as intended.

Changes:

• Removes _timeout.update_inactivity() from Http2Stream::send_body() to avoid bumping inactivity on failed send attempts.

[Copilot]

This change alters how HTTP/2 stream inactivity is tracked under flow-control / write-blocked conditions (e.g., NO_WINDOW). I couldn't find existing gold tests that exercise the NO_WINDOW path (no references in tests/), so it would be good to add a regression test that stalls an HTTP/2 stream via flow control and asserts transaction_no_activity_timeout_in fires (and also that real outbound DATA resets the timer).

[Copilot]

Removing _timeout.update_inactivity() here means the stream may no longer bump its inactivity timer after successful DATA frame sends in cases where no signal_write_event() is emitted (e.g., Http2ConnectionState::send_data_frames() can send one or more DATA frames, then stop on NO_WINDOW while more_data is still true, and it does not call signal_write_event() in that path). That can lead to premature transaction_no_activity_timeout_in even though bytes were just sent. Consider updating inactivity only when a frame is actually enqueued/sent (e.g., alongside update_sent_count() / after xmit()), rather than at the start of send_body() or on every send attempt.