openclaw - 💡(How to fix) Fix [Bug]: Delivery queue recovery loses Slack API error details (missing_scope needed/scopes fields) [1 comments, 1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

recoverPendingDeliveries in src/infra/outbound/delivery-queue.ts stringifies Slack API errors with err.message, discarding structured fields (err.data.needed, err.data.response_metadata.scopes) that identify which OAuth scope is missing. This makes missing_scope delivery failures undiagnosable from queue entries or recovery logs.

Steps to reproduce

1. Configure a Slack channel with a bot token that is missing a required OAuth scope (e.g., im:write).
2. Trigger an isolated cron job with --announce --channel slack --to "user:UXXXXXXXX".
3. Delivery fails with missing_scope — entry persisted to delivery-queue/.
4. Restart the gateway to trigger recoverPendingDeliveries.
5. Inspect lastError in the queue JSON file and recovery logs.

Expected behavior

Error should include the specific missing scope, e.g.: "An API error occurred: missing_scope (needed: im:write, granted: chat:write, users:read)"

Actual behavior

Error is only "An API error occurred: missing_scope" — the needed field and response_metadata.scopes are lost. Queue entries and logs provide no actionable information about which scope to add.

Evidence from 59 stuck queue entries all showing:

"lastError": "An API error occurred: missing_scope"

Gateway recovery logs:

2026-04-07T07:46:34.931Z warn gateway/delivery-recovery Retry failed for delivery e25a01c7: An API error occurred: missing_scope

OpenClaw version

Latest main (0.3.0-dev)

Operating system

macOS 26.3 (arm64)

Install method

pnpm dev (fork)

Model

N/A (infrastructure bug, not model-dependent)

Provider / routing chain

N/A (infrastructure bug, not provider-dependent)

Logs, screenshots, and evidence

Root cause at delivery-queue.ts:351:

const errMsg = err instanceof Error ? err.message : String(err);

Slack's @slack/web-api throws CodedError objects with structured fields:

• err.data.error — e.g. "missing_scope"
• err.data.needed — the specific scope required (e.g. "im:write")
• err.data.response_metadata.scopes — currently granted scopes
• err.data.response_metadata.acceptedScopes — scopes that would be accepted

Only err.message is captured, discarding all structured detail.

Same pattern also appears at deliver.ts:281 and deliver.ts:597.

Impact and severity

• Affected: Any user with Slack OAuth scope misconfiguration
• Severity: Medium (data loss in error reporting; blocks diagnosis of delivery failures)
• Frequency: Every missing_scope error (59 entries accumulated over ~4 weeks in one instance)
• Consequence: Users cannot determine which scope to add without manual API testing; stuck queue entries retry uselessly until max retries

Additional information

Related PRs that partially address error detail preservation in the Slack extension layer:

• #29210 — enriches missing_scope errors in send.ts (open, stale)
• #53966 — general formatSlackError() helper across Slack files (open)

Neither PR covers the delivery queue recovery path in src/infra/outbound/, which is the primary site where error details are needed for diagnosis of stuck entries.

Note: missing_scope is also not in the PERMANENT_ERROR_PATTERNS list in delivery-queue.ts, so these entries retry 5 times instead of being immediately moved to failed/. This is arguably a secondary issue — missing_scope will never self-resolve.