Duplicated getRuntimeSnapshot guard logic

The identical try/catch wrapper for getRuntimeSnapshot() is copy-pasted verbatim at lines 811–819 and again at lines 1082–1090. If the error-handling or logging details need to change in the future they'd need to be updated in both places.

Consider extracting it into a small local helper near the call sites, e.g.:

const safeGetRuntimeSnapshot = () => {
  try {
    return getRuntimeSnapshot();
  } catch (err) {
    log.warn("getRuntimeSnapshot() failed during health refresh", { error: err });
    return undefined;
  }
};

Then each call site becomes a one-liner: return refreshGatewayHealthSnapshot({ ...opts, runtimeSnapshot: safeGetRuntimeSnapshot() });

This is a comment left during a code review.
Path: src/gateway/server.impl.ts
Line: 811-819

Comment:
**Duplicated `getRuntimeSnapshot` guard logic**

The identical try/catch wrapper for `getRuntimeSnapshot()` is copy-pasted verbatim at lines 811–819 and again at lines 1082–1090. If the error-handling or logging details need to change in the future they'd need to be updated in both places.

Consider extracting it into a small local helper near the call sites, e.g.:

```ts
const safeGetRuntimeSnapshot = () => {
  try {
    return getRuntimeSnapshot();
  } catch (err) {
    log.warn("getRuntimeSnapshot() failed during health refresh", { error: err });
    return undefined;
  }
};
```

Then each call site becomes a one-liner: `return refreshGatewayHealthSnapshot({ ...opts, runtimeSnapshot: safeGetRuntimeSnapshot() });`

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

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Fixed in f94c29d — extracted safeGetRuntimeSnapshot() helper so the try/catch guard lives in one place.

Avoid scheduling refreshes on ignored runtime snapshots

This follow-up refresh is triggered whenever pendingRuntimeSnapshot is set, but getHealthSnapshot currently ignores runtimeSnapshot entirely (its params in src/commands/health.ts only read timeoutMs and probe). In practice, concurrent health calls can now cause back-to-back full refreshes with identical payloads, which increases probe/load cost under polling without improving freshness. Either plumb runtimeSnapshot into the health computation or stop using it as the trigger for a second refresh.

Useful? React with 👍 / 👎.

Already addressed in f94c29d — getHealthSnapshot() now accepts a runtimeSnapshot param and merges runtime channel state (connected, lastConnectedAt, lastEventAt, etc.) into the channel snapshot. The follow-up refresh correctly carries the snapshot forward.

Catch errors from queued health follow-up refresh

refreshGatewayHealthSnapshot schedules a second refresh with void refreshGatewayHealthSnapshot({ probe: followUpProbe }) and drops the returned promise. If that follow-up call fails (for example, any exception bubbling out of getHealthSnapshot), it becomes an unhandled rejection. This is production-impacting because the global unhandled-rejection handler exits the process, so concurrent health requests that trigger this path can crash the gateway instead of just logging a refresh failure.

Useful? React with 👍 / 👎.

Fixed in 5291275 — added .catch(() => {}) to the void follow-up call so any exceptions are silently swallowed.

Schedule probe follow-ups when runtimeSnapshot capture fails

If safeGetRuntimeSnapshot() catches the getRuntimeSnapshot() error and returns undefined (src/gateway/server.impl.ts:757-764), a concurrent probe:true call only updates pendingProbe. Because this finally block only queues a second refresh when pendingRuntimeSnapshot exists, that verbose health request still resolves to the in-flight probe:false snapshot instead of re-probing. In other words, the config-error path this patch is targeting can still silently drop the caller's probe intent.

Useful? React with 👍 / 👎.

Fixed in 596102e — the finally block now also triggers a follow-up refresh when hadPendingProbe is set, so a probe request that arrives after safeGetRuntimeSnapshot() has already returned undefined is not silently dropped.

Queue follow-up when probe intent changes without snapshot

The finally path only triggers a second refresh when pendingRuntimeSnapshot is present, so if a concurrent caller requests probe: true while safeGetRuntimeSnapshot() returns undefined (its caught-error path), the probe intent is still dropped. In that sequence this function returns the in-flight probe:false result, clears pendingProbe, and never schedules a re-probe, so the caller gets stale non-probed health despite explicitly asking for probing.

Useful? React with 👍 / 👎.

Fixed in 596102e — same root cause as the previous item. The finally block now captures hadPendingProbe before clearing pendingProbe, and triggers a follow-up refresh when either pendingRuntimeSnapshot or hadPendingProbe is set. This ensures a probe:true call that arrives after safeGetRuntimeSnapshot() has already returned undefined still triggers a refresh with probe:true.

Capture runtime snapshots only after dedupe decides to refresh

This wrapper calls safeGetRuntimeSnapshot() before refreshGatewayHealthSnapshot decides whether a refresh is already in flight, so every overlapping health request still pays the full snapshot cost even when dedupe would otherwise reuse the existing promise. In busy polling setups, this repeatedly walks all channel accounts (getRuntimeSnapshot iterates plugins/accounts and resolves each account), which increases CPU/load and can spam warning logs in the same config-error scenario this patch is trying to soften.

Useful? React with 👍 / 👎.

Preserve queued probe=false overrides during refresh

refreshGatewayHealthSnapshot only records pending probe intent when opts.probe is true, so a later probe:false call cannot clear an earlier queued probe. In the sequence “in-flight probe:false refresh → concurrent probe:true request → later concurrent probe:false request”, the finally block still schedules a follow-up probe and the later caller can end up waiting for that extra probe cycle, which adds avoidable probe latency/load and violates the function’s own “latest caller preference” behavior.

Useful? React with 👍 / 👎.