Reset keepalive state on reconnect

[caspervonb]

A reconnect caused by reaching max_outstanding_pings inherited the maxed _pings_outstanding counter: the reconnect success path restored the connection and subscriptions but never reset keepalive state. The new write loop saw the stale counter on its first idle timeout and force-disconnected again one ping_interval later — reconnecting forever.

Reset _pings_outstanding / _last_ping_sent / _last_pong_received on reconnect, mirroring initial-connect setup. Covered by a regression test that puts the client in the ping-exhausted state, forces a reconnect, and asserts the counter is cleared and no spiral follows.

[synadia-claude-reviewer]

Claude finished @caspervonb's task in 1m 34s —— View job

---

PR Review: Reset keepalive state on reconnect

• Gather context (PR diff, changed files)
• Review implementation changes in nats-core/src/nats/client/__init__.py
• Review test coverage in nats-core/tests/test_client.py
• Post inline comments and summary

---

Fix is correct and the root cause analysis is sound. The three-field reset (_pings_outstanding, _last_pong_received, _last_ping_sent) exactly mirrors __init__'s setup and is placed at the right point in the reconnect path — after the new connection is confirmed with a PONG, before the new read/write tasks start. Without the fix, _write_loop would see _pings_outstanding >= _max_outstanding_pings on its first idle timeout and immediately call _force_disconnect() again.

_pong_waker doesn't need resetting — _ping() calls self._pong_waker.clear() before every use, so any stale "set" state from the prior connection is harmless.

Two minor notes left as inline comments:

1. get_event_loop() vs get_running_loop() — the reconnect path correctly uses asyncio.get_running_loop().time() but __init__ still uses the deprecated asyncio.get_event_loop().time() pattern. Not introduced by this PR, but worth aligning.
2. Comment length — the 4-line block comment is more verbose than the one-line-max style in CLAUDE.md; the why can be captured in one line.

Test is solid — directly setting _pings_outstanding = _max_outstanding_pings gives a deterministic repro without needing a mock server, and the 3-interval sleep (ping_interval=0.2, sleep=0.6) is long enough to catch a spiral without flaking. The post-reconnect pub/sub round-trip confirms the connection stays usable.

[synadia-claude-reviewer]

Minor inconsistency: __init__ timestamps these fields with asyncio.get_event_loop().time() (lines 457–458), while the reconnect path uses asyncio.get_running_loop().time(). Both return the same loop time in an async context, and get_running_loop() is actually the more correct call here — but the inconsistency could confuse a future reader auditing timer semantics. Worth aligning __init__ to get_running_loop() in a follow-up (or here).

[synadia-claude-reviewer]

The comment is accurate and the bug it describes is non-obvious, so a comment is warranted. CLAUDE.md asks for one-line max though — something like # Reset keepalive state; a ping-exhaustion reconnect must not inherit a stale counter. would capture the why without the four lines.