fix(envoy-client): ignore pings from earlier connections in the silence check

[eersnington]

No description provided.

[claude]

Review

Small, well-reasoned fix. The new integration test drives a real envoy through a reconnect.

What it does: install_connection_with_http resets last_ping_ts to 0 on each new connection, so a ping from the old connection can't trip the silence deadline before the new connection's first ping. The first ping is forwarded to the envoy loop so it re-arms the silence timer.

Notes

• Reset vs. stale-session ping race. forward_to_envoy checks the session before storing the ping timestamp. A late ping from the old session could land after the reset and restore a stale timestamp. The window is tiny and the failure is the old behavior, but doing the session check and store under one guard would close it. I didn't verify whether the surrounding code already does.
• is_ping_healthy side effect. It now returns false from reconnect until the first ping. That seems right, but worth confirming upstream health checks tolerate a short unhealthy window after each reconnect.
• Waking the loop by re-forwarding the first ping. It works, and the comment in envoy.rs explains it. A dedicated wake message would be more explicit.
• Test timing. It relies on real wall-clock sleeps (2s deadline, 200ms and 300ms margins). The early.is_err() check could flake on a loaded CI runner. CLAUDE.md prefers deterministic tests, though real sockets make that awkward.
• PR body is empty. A short bullet list would help.

Style matches CLAUDE.md (hard tabs, tests under tests/, no em dashes). No security concerns. Looks good to merge, with the optional race hardening above.

[the-company-company]

🔴 1 high-severity finding

_{Reviewed commit 831507a.}

[the-company-company]

🔴 High · Keep a deadline before the first ping

Clearing this to the sentinel disables the only ping-silence deadline for the new session. ToEnvoyInit subsequently clears lost_timeout, so if the engine sends Init and commands and then crashes or the link becomes half-open before its first ping, engine_ping_silence_deadline_ms returns None forever while the newly started actors keep running; the engine can meanwhile declare this envoy lost and reallocate them, violating the single-writer invariant. Track a separate per-session/Init baseline (or equivalent first-ping grace deadline) so the old ping is ignored without leaving the pre-first-ping state unbounded.

[eersnington]

slop? the engine sends Init b4 it refreshes the envoys liveness

conn.rs:146   send Init                       ← envoy would reset its silence baseline here
conn.rs:278   claim_registration
conn.rs:423     write LastPingTsKey           ← engine resets its clock here (or not, if the claim fails)
conn.rs:293   send missed commands
lib.rs:249    ping task → update_ping, then ping

[eersnington]

@claude blast him

[abcxff]

Stack for rivet-dev/rivet

Current stack:

• #5843 fix(envoy-client): keep the ping silence deadline bounded ac …
• #5838 fix(envoy-client): ignore pings from earlier connections in … 👈
• #5823 fix(envoy-client): declare actors lost before the engine can …
• #5824 fix(rivetkit): stop lost actor generations immediately
• #5821 fix(envoy-client): signal lost actor generations synchronous …
• #5822 fix(rivetkit): isolate workflow run state per actor generati …
• #5825 fix(rivetkit-napi): key actor runtime state by generation

Dependencies:

• #5816 chore(release): update version to 2.3.23
• main

Get stack: forklift get 5838
Push local edits: forklift submit
Merge when ready: forklift merge 5838

_{change uxuuvwzu}