Unhandled rejection on reconnect onConnectError during poll delay

When the websocket drops and the follow loop is in the delay(interval) sleep between polls, onClose fires first and calls resetReady(), creating a fresh ready deferred. The client then schedules a reconnect (after backoffMs, starting at 1 000 ms). If that reconnect attempt fails quickly (e.g. "connection refused") before delay(interval) finishes, onConnectError rejects ready.promise, and then onClose calls resetReady() again — replacing ready with a new deferred.

Because waitUntilReady() hasn't been called yet (the follow loop is still sleeping), nothing ever awaits the rejected promise. In Node.js 15+ the process will crash with UnhandledPromiseRejection.

The simplest guard is to silence the old promise before replacing it:

const resetReady = () => {
  ready.promise.catch(() => {}); // prevent unhandled rejection if nobody is awaiting it
  ready = createDeferred<void>();
};

Alternatively, store the last connect error and re-throw it on the next waitUntilReady() call so the caller still sees the error.

This is a comment left during a code review.
Path: src/cli/logs-cli.ts
Line: 107-109

Comment:
**Unhandled rejection on reconnect `onConnectError` during poll delay**

When the websocket drops and the follow loop is in the `delay(interval)` sleep between polls, `onClose` fires first and calls `resetReady()`, creating a fresh `ready` deferred. The client then schedules a reconnect (after `backoffMs`, starting at 1 000 ms). If that reconnect attempt fails quickly (e.g. "connection refused") before `delay(interval)` finishes, `onConnectError` rejects `ready.promise`, and then `onClose` calls `resetReady()` again — replacing `ready` with a new deferred.

Because `waitUntilReady()` hasn't been called yet (the follow loop is still sleeping), nothing ever awaits the rejected promise. In Node.js 15+ the process will crash with `UnhandledPromiseRejection`.

The simplest guard is to silence the old promise before replacing it:

```typescript
const resetReady = () => {
  ready.promise.catch(() => {}); // prevent unhandled rejection if nobody is awaiting it
  ready = createDeferred<void>();
};
```

Alternatively, store the last connect error and re-throw it on the next `waitUntilReady()` call so the caller still sees the error.

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

requestTimeoutMs now propagates into one-shot client options

Before this refactor, executeGatewayRequestWithScopes never set requestTimeoutMs when constructing the GatewayClient, so the client used its 30 s default as a fallback for any request that didn't supply its own timeoutMs. Now requestTimeoutMs: timeoutMs is included in clientOptions from resolveGatewayClientConnectionWithScopes, meaning one-shot callers that pass neither opts.timeoutMs to their client.request() call nor an explicit timeout to callGateway()/callGatewayCli() will now see a 10 s per-request fallback (the default from resolveGatewayCallTimeout) instead of 30 s.

In practice this is harmless because the safeTimerTimeoutMs outer timer already fires at 10 s, but it changes observable behavior for any caller that relied on the 30 s default per-request timeout. If this is intentional, a brief comment here would clarify it for future readers.

This is a comment left during a code review.
Path: src/gateway/call.ts
Line: 905

Comment:
**`requestTimeoutMs` now propagates into one-shot client options**

Before this refactor, `executeGatewayRequestWithScopes` never set `requestTimeoutMs` when constructing the `GatewayClient`, so the client used its 30 s default as a fallback for any request that didn't supply its own `timeoutMs`. Now `requestTimeoutMs: timeoutMs` is included in `clientOptions` from `resolveGatewayClientConnectionWithScopes`, meaning one-shot callers that pass neither `opts.timeoutMs` to their `client.request()` call nor an explicit timeout to `callGateway()`/`callGatewayCli()` will now see a 10 s per-request fallback (the default from `resolveGatewayCallTimeout`) instead of 30 s.

In practice this is harmless because the `safeTimerTimeoutMs` outer timer already fires at 10 s, but it changes observable behavior for any caller that relied on the 30 s default per-request timeout. If this is intentional, a brief comment here would clarify it for future readers.

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

Treat stream-disconnect errors as retryable in follow mode

createFollowLogsClient pushes "gateway log stream disconnected" into the follow queue on socket close, but isRetryableFollowStartupError does not match that message (nor "gateway not connected" from client.request). In logs --follow, a transient gateway restart therefore falls into the non-retryable path and exits with a fatal gateway error instead of re-waiting/re-subscribing. This breaks long-running follow sessions whenever the websocket drops briefly.

Useful? React with 👍 / 👎.

Surface poll errors instead of silently dropping log subscribers

The catch-all in pollSubscriber unsubscribes on any exception without notifying the client or closing the socket. A transient file race (for example, ENOENT between stat and open during rotation) will permanently remove that subscriber while the websocket stays connected, leaving follow clients blocked waiting for logs.appended that never arrive. This should either retry on the next poll or close/error the socket so clients can recover.

Useful? React with 👍 / 👎.

Re-check subscriber membership before sending appended logs

pollSubscriber can continue past await resolveLogFile(...) / await readLogSlice(...) and call socket.send(...) even after logs.unsubscribe removed that connId from subscribers. In that race (for example, unsubscribe during slow filesystem reads), the client can still receive a logs.appended event after unsubscribe has already succeeded, which violates the method contract and can produce confusing extra lines. Add a post-read guard (e.g., ensure the current map entry still matches this subscriber or mark inactive on unsubscribe) before sending.

Useful? React with 👍 / 👎.

Skip socket close for stale unsubscribed pollers

pollSubscriber now checks subscriber identity before sending events, but the catch path still unconditionally closes subscriber.socket. If logs.unsubscribe (or a replacement logs.subscribe) wins while a poll is in flight and that stale poll later throws (for example during log-file rotation races), this closes the still-active websocket unexpectedly and drops unrelated RPC traffic on that connection. Gate the close path on subscribers.get(subscriber.connId) === subscriber (and active status) before closing.

Useful? React with 👍 / 👎.

Return logs.tail payload from fetchLogs

fetchLogs validates the logs.tail response but never returns it, so callers receive undefined. In normal openclaw logs (non-follow) flow this makes emitLogsPayload crash when it reads payload.lines, and the command falls into the generic gateway-error path even when the gateway is healthy. Return the validated payload so non-follow log tailing still works.

Useful? React with 👍 / 👎.

Keep task-registry shutdown hook in close handler

This shutdown section now invokes logStreamStop but no longer calls stopTaskRegistryMaintenance, even though that callback is still passed by startGatewayServer. That leaves task-registry maintenance running after gateway shutdown/restart in-process, so background sweeps can continue mutating task state outside the server lifecycle. Keep the existing task-maintenance stop call alongside the new log-stream stop.

Useful? React with 👍 / 👎.

Re-export exec-approval param types from protocol index

The protocol/index.ts type export list dropped ExecApprovalGetParams, ExecApprovalRequestParams, and ExecApprovalResolveParams while adding log-subscribe types. That creates an unintended breaking change for downstream code importing those exec-approval types from this public barrel. Keep the log-subscribe exports additive and restore the removed exec-approval type exports.

Useful? React with 👍 / 👎.

Default logs.tail limits before calling readLogSlice

logs.tail now forwards p.limit/p.maxBytes directly even though both params are optional, so valid calls like logs.tail {} pass undefined into readLogSlice. That function clamps numeric inputs and eventually computes a NaN buffer length, which throws and returns UNAVAILABLE instead of tail data for clients that omit these optional fields. Preserve the old behavior by applying defaults (like DEFAULT_LIMIT/DEFAULT_MAX_BYTES) before invoking readLogSlice.

Useful? React with 👍 / 👎.

Include resolved file in logs.tail responses

logs.tail now responds with result from readLogSlice, but readLogSlice does not include a file field, so successful responses violate the declared LogsTailResult contract and can break typed clients that decode file as required (including the updated Swift model) or depend on it for file-rotation state. Returning { file, ...result } is needed to keep the wire payload backward-compatible.

Useful? React with 👍 / 👎.

Restore loopback pairing fallback for logs.tail fetches

fetchLogs now directly awaits callGatewayFromCli("logs.tail", ...) without the previous pairing-required fallback path, so when a local loopback gateway requests pairing, openclaw logs exits through the generic gateway error flow instead of reading the configured local log file. This is a user-facing regression for unpaired local setups where logs were previously still available.

Useful? React with 👍 / 👎.