PR #67959: fix(channels): parallelize status probes

• Repository: openclaw/openclaw
• Author: yeyitech
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67959

Description (problem / solution / changelog)

Summary

• Problem: openclaw channels status --probe timed out with multiple configured accounts because the gateway probed accounts sequentially and the CLI default timeout stayed at 10s.
• Why it matters: operators saw a misleading gateway-timeout error and lost live probe data even when the gateway itself was healthy.
• What changed: channels.status now overlaps per-channel and per-account probe work while preserving deterministic output order, and channels status --probe now defaults to a 30000ms timeout when --timeout is omitted.
• What did NOT change (scope boundary): per-account probeAccount/auditAccount contracts, non-probe channels status, and explicit --timeout behavior remain unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #67938
• Related #67937
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: src/gateway/server-methods/channels.ts awaited probe/audit work in nested loops, so total probe time scaled with the sum of all accounts instead of the slowest account. src/cli/channels-cli.ts and src/commands/channels/status.ts also kept the omitted-timeout default at 10000ms, which was too short for multi-account probe runs.
• Missing detection / guardrail: there was no regression coverage asserting concurrent probe scheduling or the probe-mode default timeout.
• Contributing context (if known): slow channels such as Telegram can already consume most of a 10s per-account budget, so sequential probing made the aggregate request exceed the CLI timeout quickly.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/server-methods/channels.status.test.ts, src/commands/channels.status.command-flow.test.ts, src/cli/channels-cli.test.ts
• Scenario the test should lock in: probe mode overlaps account work without reordering account output, probe mode uses a 30000ms default when --timeout is omitted, and explicit --timeout still wins.
• Why this is the smallest reliable guardrail: the regression sits in gateway request assembly and CLI option/default plumbing; these tests hit both seams directly without needing live channel credentials.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw channels status --probe now completes much faster on multi-account setups because probe work is no longer serialized across every account.
• Omitting --timeout in probe mode now uses 30000ms instead of 10000ms.
• Non-probe openclaw channels status still defaults to 10000ms.

Diagram (if applicable)

Before:
[channels status --probe] -> [gateway probes account 1] -> [account 2] -> [account 3] -> [CLI hits 10s timeout]

After:
[channels status --probe] -> [gateway probes accounts concurrently] -> [results kept in account order] -> [CLI receives payload within the larger default budget]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local Node 22 / pnpm workspace
• Model/provider: N/A
• Integration/channel (if any): channel status gateway path
• Relevant config (redacted): multi-account channel config, no secrets needed for tests

Steps

1. Configure multiple channel accounts and run openclaw channels status --probe.
2. Observe that the old path serialized per-account probes and could exceed the default timeout.
3. Run the same command after this change and verify the request overlaps account work and uses the higher default timeout when omitted.

Expected

• Probe mode should not time out solely because multiple configured accounts are probed sequentially.

Actual

• Before this change, the CLI could fail with gateway timeout after 10000ms even when the gateway was reachable.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: targeted tests for gateway probe concurrency/order, probe-mode timeout defaulting, explicit timeout override behavior, and CLI option passthrough; full pnpm build; full pnpm check.
• Edge cases checked: non-probe status keeps the 10s default; account payload order remains stable even when work overlaps.
• What you did not verify: live multi-account probe timing against real external channel credentials.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: parallel probe scheduling could expose ordering assumptions in status payload assembly.
  • Mitigation: results are collected with Promise.all(...), and regression coverage asserts stable account ordering.
• Risk: a longer default probe timeout could delay failure when a user expects a hard 10s limit.
  • Mitigation: this only applies when --probe is used without an explicit override, and --timeout still takes precedence.

Changed files

• src/cli/channels-cli.test.ts (added, +70/-0)
• src/cli/channels-cli.ts (modified, +1/-1)
• src/commands/channels.status.command-flow.test.ts (modified, +50/-0)
• src/commands/channels/status.ts (modified, +7/-1)
• src/gateway/server-methods/channels.status.test.ts (modified, +106/-0)
• src/gateway/server-methods/channels.ts (modified, +79/-65)