This is the kind of failure where “reconnect” needs an owner, not just a timer. I’d give each stream a connection generation and allow only that generation to schedule its replacement; a takeover/normal close should invalidate the old generation before any retry fires. Then treat Retry-After as a server-side backoff contract, while keeping transport-connected, accepted, and actually-carried states separate. Otherwise one dropped stream becomes a self-amplifying fan-out loop—and the dashboard reports availability loss after the client has already caused it.