Greptile Summary

This PR adds a configurable reconnect grace period (default 5 minutes) to the channel health monitor, preventing it from tearing down and recreating Discord providers during the brief window when the gateway's own reconnect logic (resume/identify) is still in progress. The root cause — health checks racing with built-in reconnect cycles — is well-diagnosed and the fix is correctly scoped.

Key changes:

• DEFAULT_RECONNECT_GRACE_MS (5 min) added alongside the existing startup and stale-event constants.
• evaluateChannelHealth now returns healthy: true for a running-but-disconnected channel if the disconnect is newer than reconnectGraceMs, falling back to lastEventAt as a proxy when lastDisconnect is unavailable.
• channel-health-monitor.ts extracts lastDisconnect.at from the runtime snapshot and maps it to the typed lastDisconnectAt field on ChannelHealthSnapshot.
• 7 new tests thoroughly cover the grace-period paths; the updated "stuck channel" test correctly uses explicit timestamps to assert past-grace behavior.

Issues found:

• lastDisconnect is not declared in ChannelAccountSnapshot so it is accessed via an unsafe as { lastDisconnect?: unknown } cast with manual runtime shape checks, rather than through the type system. Adding the field to ChannelAccountSnapshot would eliminate this bypass and simplify the extraction to a single optional-chain.
• The startup log (started (interval: …s, startup-grace: …s, …)) does not include reconnectGraceMs, making the configured value invisible in operational logs — worth adding alongside the other timing parameters.

Confidence Score: 4/5

• Safe to merge; the logic is sound and well-tested, with two minor polish issues.
• The fix correctly addresses the documented race condition, is gated on the running flag so it cannot suppress restarts for stopped channels, and is well-covered by tests. The two issues (unsafe lastDisconnect type cast and missing reconnectGraceMs in the startup log) are style/observability concerns that do not affect correctness.
• src/gateway/channel-health-monitor.ts — the lastDisconnect type cast on lines 137–144 should be replaced by properly typing the field in ChannelAccountSnapshot.

This is a comment left during a code review.
Path: src/gateway/channel-health-monitor.ts
Line: 137-144

Comment:
**Unsafe type cast for `lastDisconnect`**

`status` is typed as `ChannelAccountSnapshot`, which does not appear to declare a `lastDisconnect` field, so it is accessed by casting `status as { lastDisconnect?: unknown }`. This bypasses TypeScript's type system and will silently stop working correctly if the runtime shape of the field changes.

The correct fix is to add `lastDisconnect?: { at?: number } | null` to `ChannelAccountSnapshot` (in `src/channels/plugins/types.ts` or wherever it is declared). Once typed, the entire extraction block can be simplified to a one-liner:

```ts
const lastDisconnectAt = typeof status.lastDisconnect?.at === "number"
  ? status.lastDisconnect.at
  : null;
```

As written, the cast and the manual shape-checks work at runtime, but they are invisible to the type checker and will not catch future structural regressions.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/gateway/channel-health-monitor.ts
Line: 211-212

Comment:
**Startup log omits `reconnectGraceMs`**

The startup `log.info` records `interval`, `startup-grace`, and `channel-connect-grace`, but does not include the new `reconnectGraceMs` value. Given that this parameter is the core of the fix (and misconfiguring it would silently change how quickly the monitor intervenes after a disconnect), it should appear in the startup log alongside the other timing values.

```suggestion
    log.info?.(
      `started (interval: ${Math.round(checkIntervalMs / 1000)}s, startup-grace: ${Math.round(timing.monitorStartupGraceMs / 1000)}s, channel-connect-grace: ${Math.round(timing.channelConnectGraceMs / 1000)}s, reconnect-grace: ${Math.round(timing.reconnectGraceMs / 1000)}s)`,
    );
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 14dee8d}

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Keep this PR open. Current main still lacks the PR's central reconnect-grace behavior: after startup connect grace, a running channel with connected: false is still unhealthy immediately and the health monitor can restart it. Main now has related hardening such as cooldown/hour caps and typed Discord lastDisconnect data, but those do not supersede the delayed-intervention behavior proposed here.

Best possible solution:

Keep this PR open as a useful implementation candidate. Rebase it onto current main, add a generic reconnectGraceMs/lastDisconnectAt path in the shared health policy, consume typed lastDisconnect.at from runtime snapshots with a clear fallback policy, update both health-monitor and readiness call sites, and add focused tests for recent disconnects, expired disconnects, stopped channels, stale sockets, active runs, and restart caps.

What I checked:

• Current health policy has no reconnect grace contract: ChannelHealthSnapshot has no lastDisconnectAt input and ChannelHealthPolicy only carries channelId, now, staleEventThresholdMs, and channelConnectGraceMs; there is no reconnectGraceMs field on current main. (src/gateway/channel-health-policy.ts:3, bdfb408ce6ee)
• Disconnected running channels still fail immediately: After startup connect grace, evaluateChannelHealth returns { healthy: false, reason: "disconnected" } as soon as snapshot.connected === false, with no check against disconnect age or lastDisconnect.at. (src/gateway/channel-health-policy.ts:112, bdfb408ce6ee)
• Monitor does not plumb reconnect timing: ChannelHealthTimingPolicy includes startup grace, channel connect grace, and stale-event threshold only. The monitor builds the policy without reconnect grace and passes the raw account status to evaluateChannelHealth. (src/gateway/channel-health-monitor.ts:26, bdfb408ce6ee)
• Existing tests still assert restart for running disconnected channels: The health monitor test for a running but not connected channel with lastStartAt five minutes ago expects stopChannel, resetRestartAttempts, and startChannel, which is the behavior this PR is trying to delay during reconnect grace. (src/gateway/channel-health-monitor.test.ts:277, bdfb408ce6ee)
• Readiness shares the immediate-disconnect policy: Readiness constructs the same ChannelHealthPolicy shape without reconnect grace, and its test still reports a disconnected managed Discord channel as not ready after startup grace. A rebased implementation needs to update this surface deliberately. (src/gateway/server/readiness.ts:72, bdfb408ce6ee)
• Discord disconnect timestamp is available to consume: Current main already types ChannelAccountSnapshot.lastDisconnect with an at field, and Discord lifecycle code publishes that field on gateway close/runtime-not-ready events, so the remaining gap is policy plumbing rather than a missing status API. (src/channels/plugins/types.core.ts:200, bdfb408ce6ee)

Remaining risk / open question:

• Merging the PR as-is against current main may miss the newer readiness call site, which also constructs ChannelHealthPolicy and currently treats post-startup disconnects as failures.
• The rebased change needs to preserve current busy-run handling, stale-socket transport-activity behavior, cooldown/hourly restart caps, and non-running/gave-up recovery paths.
• The reconnect grace window must be bounded so it does not hide genuinely dead channels indefinitely.

Codex review notes: model gpt-5.5, reasoning high; reviewed against bdfb408ce6ee.

ProjectClownfish could not safely update this branch, so it opened a narrow replacement PR instead.

Replacement PR: #73989
Source PR: #45712
Contributor credit is preserved in the replacement PR body and changelog plan.