fix: voice-call CLI gateway delegation path actionable regressions

[clawsweeper]

Summary

Found two actionable regressions in the new voice-call CLI gateway delegation path. The main issue is a fixed 5s gateway request timeout applied to operations that can legitimately wait much longer.

What ClawSweeper Is Fixing

• Medium: Gateway-delegated voicecall continue times out long before the voice-call turn timeout (reliability)
  • File: extensions/voice-call/src/cli.ts:48
  • Evidence: The CLI now sends every delegated voice-call gateway RPC with timeout: "5000" via callVoiceCallGateway. That includes voicecall.continue at extensions/voice-call/src/cli.ts:438. But continueCall speaks, starts listening, and then awaits waitForFinalTranscript at extensions/voice-call/src/manager/outbound.ts:377; the configured transcript timeout defaults to 180000 ms in extensions/voice-call/src/config.ts:343.
  • Impact: In normal conversational use, waiting more than 5 seconds for the caller to answer is expected. The CLI will return gateway request timeout for voicecall.continue while the gateway-side turn may keep running until the real transcript timeout. The operator loses the transcript result and may retry into an already-active turn.
  • Suggested fix: Do not use the same 5s timeout for long-running voice-call RPCs. Use the voice-call config timeout for continue, a larger provider-operation timeout for start/call, or split long operations into accepted/operation-id polling.
  • Confidence: high
• Low: Delegated CLI failures lose actionable voice-call error messages (regression)
  • File: extensions/voice-call/index.ts:305
  • Evidence: The voice-call gateway handlers report failures as respond(false, { error: "..." }), for example missing call/message data at extensions/voice-call/index.ts:305, manager failures at extensions/voice-call/index.ts:310, and to required at extensions/voice-call/index.ts:459. Gateway responses carry errors in the third error argument, and the client rejects failed frames using parsed.error?.message ?? "unknown error" at src/gateway/client.ts:865. The new CLI delegation rethrows non-transport gateway errors at extensions/voice-call/src/cli.ts:95.
  • Impact: When the gateway is reachable but the voice-call operation fails, the CLI can report unknown error instead of the real cause such as to required, fromNumber not configured, provider setup errors, or Already waiting for transcript. The pre-commit local-runtime path surfaced those manager errors directly.
  • Suggested fix: Return gateway failures with the protocol error argument, for example respond(false, undefined, errorShape(..., message)), or otherwise update the gateway method wrapper/client contract so plugin { error } payload failures preserve their message for CLI callers.
  • Confidence: high

Expected Repair Surface

• extensions/voice-call/src/cli.ts
• extensions/voice-call/index.ts
• extensions/voice-call/index.test.ts

Source And Review Context

• ClawSweeper report: https://github.com/openclaw/clawsweeper/blob/main/records/openclaw-openclaw/commits/464e57360262b7e0f9a705431bedd402fe8c356b.md

• Commit under review: 464e573

• Latest main at intake: 42d73fd

• Original commit author: Peter Steinberger

• GitHub author: @steipete

• Highest severity: medium

• Review confidence: high

• Diff: e8f9c3e6dedc8b664317264a0a15f6862488edf3..464e57360262b7e0f9a705431bedd402fe8c356b

• Changed files: CHANGELOG.md, docs/cli/voicecall.md, docs/plugins/voice-call.md, extensions/voice-call/index.test.ts, extensions/voice-call/index.ts, extensions/voice-call/src/cli.ts

• Code read: changed files in full, current main versions of touched files, gateway RPC client/server framing, plugin service startup, voice-call manager outbound/timer/config paths

• Issue context: https://github.com/openclaw/openclaw/issues/72345

Expected validation

• pnpm check:changed

ClawSweeper already ran:

• pnpm docs:list
• pnpm install because node_modules was missing
• pnpm test extensions/voice-call/index.test.ts passed: 25 tests
• pnpm exec oxfmt --check --threads=1 extensions/voice-call/src/cli.ts extensions/voice-call/index.ts extensions/voice-call/index.test.ts docs/cli/voicecall.md docs/plugins/voice-call.md CHANGELOG.md passed

Known review limits:

• Did not run a live Gateway plus phone-provider call. The findings are from source-level contract tracing and focused tests.

ClawSweeper Guardrails

• Re-check the finding against latest main before changing code.
• Keep the patch to the narrowest behavior change and matching regression coverage.
• Do not merge automatically; this PR stays for maintainer review.

ClawSweeper 🐠 replacement reef notes:

• Cluster: clawsweeper-commit-openclaw-openclaw-464e57360262
• Source PRs: none
• Credit: Detected by ClawSweeper commit review for 464e573.; Original commit author: Peter Steinberger.
• Validation: pnpm check:changed

fish notes: model gpt-5.5, reasoning medium; reviewed against a1018a1.

[clawsweeper]

Codex review: needs maintainer review before merge.

What this changes:

This PR updates the bundled voice-call plugin so gateway-delegated CLI calls use operation-specific timeouts and gateway handlers return protocol-shaped errors, with focused unit coverage.

Maintainer follow-up before merge:

The patch looks functionally narrow and correct, but exact-head CI has multiple failures without a clear PR-local repair from the available annotations; a maintainer should inspect or rerun those checks before merge.

Security review:

Security review cleared: The diff only changes bundled voice-call CLI/gateway error handling and tests; it does not touch workflows, dependencies, lockfiles, package resolution, secrets, or downloaded code.

Review details

Best possible solution:

Land the narrow voice-call plugin fix once exact-head CI is green, keeping the behavior in the plugin-owned CLI/gateway handlers and preserving the existing gateway protocol contract rather than adding a broader core special case.

Do we have a high-confidence way to reproduce the issue?

Yes. The source-level reproduction is high-confidence: current main sends voicecall.continue through a 5s gateway request timeout while the manager can wait for the configured 180s transcript timeout, and current handlers put failure messages in payloads that the gateway client ignores for failed frames.

Is this the best way to solve the issue?

Yes. The PR is the narrowest maintainable direction I found: use config-derived timeouts for long voice-call RPCs and return gateway failures through the protocol error argument that the client already consumes.

Acceptance criteria:

• pnpm test extensions/voice-call/index.test.ts
• pnpm check:changed

What I checked:

• Current main uses one 5s timeout for all delegated voice-call RPCs: callVoiceCallGateway passes { json: true, timeout: VOICE_CALL_GATEWAY_TIMEOUT_MS }, and the constant is "5000"; voicecall.continue calls the same helper. (extensions/voice-call/src/cli.ts:48, 42d73fd955af)
• Current main can legitimately wait far longer than 5 seconds: waitForFinalTranscript uses ctx.config.transcriptTimeoutMs, whose default is 180000 ms; this matches the PR body's timeout regression claim. (extensions/voice-call/src/manager/timers.ts:104, 42d73fd955af)
• Current main loses delegated error messages: Voice-call gateway handlers call respond(false, { error: ... }), while the gateway client rejects failed frames from parsed.error?.message ?? "unknown error"; payload errors are not surfaced as protocol errors. (extensions/voice-call/index.ts:259, 42d73fd955af)
• PR head changes the timeout behavior at the intended voice-call CLI surface: The PR adds default, operation, and transcript-buffer timeout constants; start uses resolveGatewayOperationTimeoutMs, and continue uses resolveGatewayContinueTimeoutMs(config). (extensions/voice-call/src/cli.ts:48, a1018a155855)
• PR head changes delegated failures to protocol errors: The PR introduces respondError around errorShape and uses the third respond argument for voice-call gateway failures, including invalid request errors such as missing to. (extensions/voice-call/index.ts:260, a1018a155855)
• PR head adds focused regression coverage: The tests assert voicecall.start delegates with a 35000 ms timeout, voicecall.continue uses a 130000 ms timeout when configured for 120000 ms transcripts, and delegated gateway failures use protocol error shape with INVALID_REQUEST. (extensions/voice-call/index.test.ts:505, a1018a155855)

Likely related people:

• steipete: The original gateway-delegation commit under review is mapped in the PR body to @steipete, and local path history for the central voice-call CLI/gateway files shows recent related commits by Peter Steinberger. (role: introduced behavior and recent maintainer; confidence: high; commits: 464e57360262, b2aac178d6da, ffcc0d1fe171; files: extensions/voice-call/src/cli.ts, extensions/voice-call/index.ts, extensions/voice-call/index.test.ts)

Remaining risk / open question:

• Exact-head CI is not green; the visible failing annotation is outside the PR diff, so it needs maintainer CI triage or rerun before merge.
• No live Gateway plus phone-provider call was performed in this read-only review; the functional confidence comes from source-level contract tracing and the PR's focused unit coverage.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 42d73fd955af.

[steipete]

Landed via temp rebase onto main.

• Gate: pnpm test extensions/voice-call/index.test.ts; git diff --check; pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/voice-call/index.ts extensions/voice-call/index.test.ts extensions/voice-call/src/cli.ts extensions/voice-call/src/telephony-tts.ts extensions/voice-call/src/gateway-continue-operation.ts; Testbox OPENCLAW_TESTBOX=1 pnpm check:changed
• Source commit: 7468386
• Merge commit: c39b323

Thanks @serrurco and @DougButdorf!