manifestWriteChain is permanently poisoned on any write failure

manifestWriteChain is a module-level singleton promise. If writeManifestFile throws (e.g. disk full, permission denied), manifestWriteChain is left as a rejected promise. Every subsequent call to queueDrainRestartMessage chains a .then() off a rejected promise — which is a no-op and produces a new rejected promise — so all further drain messages are silently dropped for the lifetime of the process.

The fix is to catch errors inside the chained operation so the chain always resolves:

With this change, await manifestWriteChain no longer rejects — but since queueDrainRestartMessage is already called with .catch(() => false) at the dispatch site, that's fine.

This is a comment left during a code review.
Path: src/gateway/restart-recovery.ts
Line: 436-444

Comment:
**`manifestWriteChain` is permanently poisoned on any write failure**

`manifestWriteChain` is a module-level singleton promise. If `writeManifestFile` throws (e.g. disk full, permission denied), `manifestWriteChain` is left as a rejected promise. Every subsequent call to `queueDrainRestartMessage` chains a `.then()` off a rejected promise — which is a no-op and produces a new rejected promise — so **all further drain messages are silently dropped** for the lifetime of the process.

The fix is to catch errors inside the chained operation so the chain always resolves:

```suggestion
  manifestWriteChain = manifestWriteChain
    .then(async () => {
      const manifest = await readManifestFile(restartConfig.manifestPath);
      if (!manifest) {
        return;
      }
      manifest.queuedMessages.push(queued);
      await writeManifestFile(restartConfig.manifestPath, manifest);
      queuedToManifest = true;
    })
    .catch(() => {
      // Prevent a write failure from permanently rejecting the chain.
    });
```

With this change, `await manifestWriteChain` no longer rejects — but since `queueDrainRestartMessage` is already called with `.catch(() => false)` at the dispatch site, that's fine.

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

Async SIGTERM handler races with concurrent signals

onSigterm now defers the request() call until an async file-read completes. During that brief window, shuttingDown is still false, so a concurrent SIGINT (or a second SIGTERM from the supervisor retrying) will call request("stop", ...), set shuttingDown = true, and start a clean shutdown — without writing the restart manifest. When the original SIGTERM's async resolves and calls request("service-restart", ...), it is silently ignored by the if (shuttingDown) return guard.

The intent file has already been consumed (unlinked) by consumeGatewayRestartIntent, so on the next startup clearGatewayRestartIntent is a no-op and recoverGatewayRestartManifest finds no manifest, meaning session recovery is silently skipped for that restart.

This is unlikely in normal operation, but launchd/systemd will sometimes escalate with a second SIGTERM if the process hasn't exited quickly. Consider atomically setting a "SIGTERM in-flight" flag on entry and short-circuiting any concurrent signal path that would turn a service-restart into a plain stop.

This is a comment left during a code review.
Path: src/cli/gateway-cli/run-loop.ts
Line: 192-201

Comment:
**Async SIGTERM handler races with concurrent signals**

`onSigterm` now defers the `request()` call until an async file-read completes. During that brief window, `shuttingDown` is still `false`, so a concurrent SIGINT (or a second SIGTERM from the supervisor retrying) will call `request("stop", ...)`, set `shuttingDown = true`, and start a clean shutdown — **without writing the restart manifest**. When the original SIGTERM's async resolves and calls `request("service-restart", ...)`, it is silently ignored by the `if (shuttingDown) return` guard.

The intent file has already been consumed (unlinked) by `consumeGatewayRestartIntent`, so on the next startup `clearGatewayRestartIntent` is a no-op and `recoverGatewayRestartManifest` finds no manifest, meaning session recovery is silently skipped for that restart.

This is unlikely in normal operation, but launchd/systemd will sometimes escalate with a second SIGTERM if the process hasn't exited quickly. Consider atomically setting a "SIGTERM in-flight" flag on entry and short-circuiting any concurrent signal path that would turn a service-restart into a plain stop.

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

Guard readiness gate against invalid config

This new early gate runs evaluateGatewayRestartReadinessGate() before the existing runServiceRestart preflight validation, and that helper defaults to loadConfig(). If openclaw.json is malformed or schema-invalid, restart now throws out of runDaemonRestart instead of reaching the established getConfigValidationError path that prints actionable restart/doctor guidance. In practice, openclaw gateway restart can crash with a raw config parse error rather than the expected structured failure output.

Useful? React with 👍 / 👎.

Block restarts when active count meets threshold

The readiness gate uses totalActive > readinessGateThreshold, which allows restart without --force when active work equals the configured threshold. With readinessGateThreshold: 1, a single running session/cron job still bypasses the gate and gets interrupted, which conflicts with the new config semantics (“minimum active work count that triggers the gate”). The comparison should be inclusive (>=) or the setting/help text should be redefined.

Useful? React with 👍 / 👎.

Prevent default readiness gate from blocking idle restarts

The new gate condition uses readiness.totalActive >= restartConfig.readinessGateThreshold, and the same module defaults readinessGateThreshold to 0, so a gateway with no active sessions/cron runs still evaluates as blocked (0 >= 0). That means openclaw gateway restart and tool-based restarts now require --force/force: true even when nothing would be interrupted, which contradicts the intended “block when active work exists” behavior and makes default restart flows fail unexpectedly.

Useful? React with 👍 / 👎.