Twitter API v2 filtered stream: total timeout or keep-alive idle detection for reconnects?

A client consuming the filtered stream endpoint (GET /2/tweets/search/stream) holds a long-lived HTTP connection the platform can drop at any time; documented guidance is to reconnect with exponential backoff and to wait longer after HTTP 429 responses using headers such as x-rate-limit-reset.

The unresolved decision is the reconnect trigger: a hard total connection lifetime that forces periodic reconnects even on a healthy stream, versus idle detection that treats an absence of tweets and keep-alive signals beyond a threshold as the drop signal. Forced reconnects add churn; idle-only detection risks a stalled connection persisting if keep-alive cadence is misjudged.

Constraints: cancellation should abort the underlying request cleanly (for example via AbortController or context cancellation) rather than leave the stream hanging; rules managed through POST /2/tweets/search/stream/rules persist independently, so reconnecting does not require re-adding them; and keep-alive intervals, timeout values, and streaming availability vary by API version and access tier, so specific numbers need checking against current documentation.

• Does a bounded connection lifetime justify its reconnect churn, given rules persist server-side?
• Should the idle threshold derive from keep-alive gaps alone, or also tolerate legitimately quiet low-traffic rule sets?
• Should client-initiated cancellation and timeout disconnects share one teardown path to avoid leaked connections?