Bound event-loop readiness wait by probe timeout

probeGateway now awaits waitForEventLoopReady() before it starts the probe timeout timer, but waitForEventLoopReady() has no upper bound and only resolves after two sub-200ms timer intervals. In environments with sustained event-loop starvation (for example, recurring synchronous work that blocks for >200ms each cycle), this preflight can loop forever, so opts.timeoutMs is never enforced and gateway probe/status can hang indefinitely instead of timing out.

Useful? React with 👍 / 👎.

No upper-bound timeout on waitForEventLoopReady

waitForEventLoopReady has no maximum wait time. If the event loop drift stays above 200 ms continuously (e.g. due to runaway CPU-intensive work, a bug in the blocking module that never finishes, or even heavy OS scheduling pressure on a loaded machine), this promise never resolves and probeGateway hangs forever.

Critically, opts.timeoutMs is passed in by callers precisely to cap how long the probe can take — but that timeout (timer) is only set up after await waitForEventLoopReady() returns, so it provides no protection during the wait.

Consider adding a hard cap, for example by racing against the caller-supplied budget:

function waitForEventLoopReady(maxWaitMs = 10_000): Promise<void> {
  return new Promise<void>((resolve) => {
    let consecutiveOk = 0;
    let prev = Date.now();
    const deadline = Date.now() + maxWaitMs;

    const check = () => {
      const now = Date.now();
      const drift = now - prev;
      prev = now;
      if (drift > 200) {
        consecutiveOk = 0;
      } else {
        consecutiveOk++;
      }
      if (consecutiveOk >= 2 || Date.now() >= deadline) {
        resolve();
      } else {
        setTimeout(check, 20);
      }
    };
    setTimeout(check, 20);
  });
}

And at the call site, pass the remaining budget:

await waitForEventLoopReady(opts.timeoutMs);

This way the total wall-clock time for probeGateway stays bounded by opts.timeoutMs regardless of how long the stall lasts.

This is a comment left during a code review.
Path: src/gateway/probe.ts
Line: 46-68

Comment:
**No upper-bound timeout on `waitForEventLoopReady`**

`waitForEventLoopReady` has no maximum wait time. If the event loop drift stays above 200 ms continuously (e.g. due to runaway CPU-intensive work, a bug in the blocking module that never finishes, or even heavy OS scheduling pressure on a loaded machine), this promise never resolves and `probeGateway` hangs forever.

Critically, `opts.timeoutMs` is passed in by callers precisely to cap how long the probe can take — but that timeout (`timer`) is only set up *after* `await waitForEventLoopReady()` returns, so it provides no protection during the wait.

Consider adding a hard cap, for example by racing against the caller-supplied budget:

```typescript
function waitForEventLoopReady(maxWaitMs = 10_000): Promise<void> {
  return new Promise<void>((resolve) => {
    let consecutiveOk = 0;
    let prev = Date.now();
    const deadline = Date.now() + maxWaitMs;

    const check = () => {
      const now = Date.now();
      const drift = now - prev;
      prev = now;
      if (drift > 200) {
        consecutiveOk = 0;
      } else {
        consecutiveOk++;
      }
      if (consecutiveOk >= 2 || Date.now() >= deadline) {
        resolve();
      } else {
        setTimeout(check, 20);
      }
    };
    setTimeout(check, 20);
  });
}
```

And at the call site, pass the remaining budget:

```typescript
await waitForEventLoopReady(opts.timeoutMs);
```

This way the total wall-clock time for `probeGateway` stays bounded by `opts.timeoutMs` regardless of how long the stall lasts.

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

Cap event-loop readiness wait by call timeout

executeGatewayRequestWithScopes now awaits waitForEventLoopReady() before starting the request timeout timer, but that helper has no upper bound and keeps rescheduling itself whenever timer drift stays above 200ms. Under sustained synchronous load (for example recurring >200ms event-loop blocks), this preflight can never resolve, so callGateway hangs indefinitely and never enforces timeoutMs; this is fresh evidence beyond the earlier probe-only report because this code path is used by all gateway RPC methods.

Useful? React with 👍 / 👎.

Include readiness preflight in probe timeout budget

probeGateway now awaits waitForEventLoopReady() before it records startedAt and before it arms the probe timeout, but the new helper defaults to waiting up to 10,000ms (src/gateway/event-loop-ready.ts) while probe budgets are often much smaller (for example the 800ms local loopback budget used by gateway status); in the starvation scenario this patch targets, the command can therefore run far beyond the configured timeout and still report a normal probe outcome, which breaks the timeout contract and makes --timeout misleading.

Useful? React with 👍 / 👎.

Enforce call timeout before waiting for event-loop readiness

executeGatewayRequestWithScopes now awaits waitForEventLoopReady() before starting its safeTimerTimeoutMs timer, and because that helper has a fixed 10,000ms default max wait, callGateway can exceed caller-provided timeouts by up to ~10s (for example timeoutMs: 500 can take ~10.5s before failing) while still throwing gateway timeout after 500ms, which is a regression for every gateway RPC path that relies on strict timeout behavior.

Useful? React with 👍 / 👎.