[request-log] Admission ${bound} reached; oldest fail-closed

Error message

[request-log] Admission ${bound} reached; oldest fail-closed state was released.

What it means

The request-log runtime enforces admission bounds (limits on in-flight fail-closed logging state). When a bound is hit, the oldest fail-closed state is released to make room, and this warning (rate-limited to once per 30s) is emitted. It signals the logging pipeline is saturated and back-pressure is shedding load.

Source

Thrown at packages/core/src/observability/request-log-runtime.ts:636

      this.admissionOverlay.delete(requestId);
    }
  }

  private settleAdmissionOperation(operationId: number, operation: AdmissionOperation): void {
    this.admissionOperations.delete(operationId);
    if (operation.key) this.admissionOperationKeys.delete(operation.key);
    if (!operation.overlayRequestId || operation.overlayVersion === undefined) return;
    const overlay = this.admissionOverlay.get(operation.overlayRequestId);
    if (overlay?.version === operation.overlayVersion) {
      this.admissionOverlay.delete(operation.overlayRequestId);
    }
  }

  private warnAdmissionBound(bound: string): void {
    const now = Date.now();
    if (now - this.admissionLastWarningAt < 30_000) return;
    this.admissionLastWarningAt = now;
    console.warn(`[request-log] Admission ${bound} reached; oldest fail-closed state was released.`);
  }

  private ensureAdmissionHeartbeat(): void {
    if (this.admissionHeartbeatTimer || this.closed) return;
    this.admissionHeartbeatTimer = setInterval(() => {
      this.submitAdmissionOperation({
        attempts: 0,
        createdAt: Date.now(),
        key: "heartbeat",
        run: (store) => {
          store.heartbeat(this.runtimeId);
          const now = Date.now();
          if (now - this.admissionLastPrunedAt >= 60 * 60 * 1_000) {
            store.prune(now);
            this.admissionLastPrunedAt = now;
          }
        }
      });

View on GitHub (pinned to 99f24806c6)

Solutions

Investigate writer throughput: check disk I/O, storage health, and whether a writer is stuck
Reduce logging volume (raise sampling, relax capture policies) if traffic legitimately exceeds capacity
Scale or move the log store to faster storage
Treat repeated warnings as capacity planning signal — the runtime is protecting itself, but data may be dropped

Example fix

// before: verbose capture on every request
requestLog: { capture: { policy: "always", includeBodies: true } }

// after: sample and skip bodies to reduce admission pressure
requestLog: { capture: { policy: "sampled", sampleRate: 0.1, includeBodies: false } }

Defensive patterns

Strategy: fallback

Validate before calling

const canAccept = runtime.admissionUsage().inFlight < runtime.admissionUsage().limit;
if (!canAccept) degradeToFailOpenLogging();

Prevention

Provision log storage IOPS to match peak traffic
Sample or truncate captured bodies under load
Alert on repeated admission warnings as a capacity signal

When it happens

Trigger: Sustained high request volume where writers cannot drain commands fast enough; slow or blocked log storage (disk I/O stall, locked DB); many concurrent fail-closed capture operations exceeding the admission limit.

Common situations: Disk saturation or a slow filesystem causing the log writer to lag; a burst of gateway traffic; a stuck downstream writer making the queue grow unboundedly until admission control kicks in.

Related errors

AI-assisted analysis of musistudio/claude-code-router@99f24806c6 (2026-08-27). Data as JSON: /api/errors/adebc3cafa65d2fc. Report an issue: GitHub.