fix(discord): default bare numeric IDs to channel kind, classify ambiguous recipient as permanent error by jini92 · Pull Request #30198 · openclaw/openclaw

jini92 · 2026-03-01T01:24:20Z

Summary

Problem: Bare numeric Discord IDs (e.g. 1466624220632059934) thrown as "Ambiguous Discord recipient" errors, causing messages to accumulate in the delivery queue with infinite retries.
Why it matters: Any send operation using a raw channel/user ID (common in cron tasks and programmatic sends) fails silently and fills up the queue, requiring manual purge.
What changed: (1) parseRecipient in send.shared.ts now defaults bare numeric IDs to channel kind instead of throwing ambiguous errors. (2) delivery-queue.ts classifies "ambiguous discord recipient" as a permanent error to stop retry loops if the error ever surfaces through another path.
What did NOT change: Behavior for explicitly prefixed targets (user:ID, channel:ID) is unchanged.

Change Type (select all)

Bug fix

Scope (select all touched areas)

Integrations

Linked Issue/PR

Related: delivery queue retry buildup on ambiguous Discord recipient errors

User-visible / Behavior Changes

Bare numeric Discord IDs passed to --target or to: now resolve to a channel instead of erroring. Users who previously needed channel:ID prefix for programmatic sends can now use the raw ID.

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

Repro + Verification

Environment

OS: Windows 11 (x64)
Runtime/container: Node 22, openclaw gateway
Integration/channel: Discord

Steps

Configure a Discord send target as a bare numeric ID (e.g. in a cron job or skill using channel: "1466624220632059934")
Trigger a send
Observe delivery queue

Expected

Message delivered to the channel

Actual (before fix)

Ambiguous Discord recipient "1466624220632059934" error thrown
Message enters retry loop; queue accumulates

Evidence

Trace/log snippets

Before fix:

Error: Ambiguous Discord recipient "1466624220632059934". Use "user:..." for DMs or "channel:..." for channel messages.

After fix: message delivered without error.

Also cleared 7 accumulated messages from delivery queue after applying the fix.

Human Verification (required)

Verified scenarios: bare numeric channel ID, bare numeric DM ID, explicit channel:ID prefix (unchanged), explicit user:ID prefix (unchanged)
Edge cases checked: non-numeric bare strings still go through normal resolution
What you did not verify: voice channels, thread IDs as bare IDs

Compatibility / Migration

Backward compatible? Yes — explicit channel: / user: prefixes still work as before; only bare IDs change behavior (was error, now defaults to channel)
Config/env changes? No
Migration needed? No

Failure Recovery (if this breaks)

Revert: remove defaultKind: "channel" from send.shared.ts and the /ambiguous discord recipient/i entry from delivery-queue.ts
Known bad symptoms: if a bare ID was intended as a user DM but gets routed to a channel — add explicit user: prefix

Risks and Mitigations

Risk: bare numeric ID that is a user ID gets sent to a channel with the same numeric ID (if one exists)
- Mitigation: channel resolution is attempted first; Discord user IDs and channel IDs share the same snowflake space but channels are looked up first in the guild cache. Users who need explicit DM sends should use user:ID.

Default bare numeric Discord IDs to channel kind instead of throwing ambiguous recipient errors. Also classify ambiguous recipient as a permanent delivery error to prevent infinite retry queue buildup. Co-Authored-By: Claude Opus 4.6 <[email protected]>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 64f52ff9f9

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-03-01T01:26:27Z

src/discord/send.shared.ts


 function parseRecipient(raw: string): DiscordRecipient {
  const target = parseDiscordTarget(raw, {
+    defaultKind: "channel",


Apply bare-ID default in active recipient parser

Setting defaultKind: "channel" inside parseRecipient does not fix the outbound send flow, because the code paths that actually send messages (parseAndResolveRecipient callers in src/discord/send.outbound.ts) never use parseRecipient; they still construct parseOptions without defaultKind and then call parseDiscordTarget(raw, parseOptions), which continues to throw on bare numeric IDs. In practice, bare IDs still fail delivery, and with the new permanent-error classification they are now dropped immediately instead of retried, so the intended behavior change is still not applied where users send messages.

Useful? React with 👍 / 👎.

greptile-apps · 2026-03-01T01:28:31Z

Greptile Summary

This PR fixes the delivery-queue retry-loop caused by bare numeric Discord IDs throwing "Ambiguous Discord recipient" errors. The synchronous parseRecipient path is correctly patched with defaultKind: "channel", and the permanent-error safety net in delivery-queue.ts is a reasonable belt-and-suspenders addition. However, the async parseAndResolveRecipient function is not patched — it constructs parseOptions without defaultKind, so bare numeric IDs still throw the same ambiguous error when routed through that code path, leaving the original bug partially unresolved.

Key changes:

src/discord/send.shared.ts — adds defaultKind: "channel" to parseRecipient's parseOptions, defaulting bare numeric IDs to channel instead of throwing.
src/infra/outbound/delivery-queue.ts — adds /ambiguous discord recipient/i to PERMANENT_ERROR_PATTERNS so any remaining occurrences of this error move the entry to failed/ immediately instead of retrying forever.
parseAndResolveRecipient (also in send.shared.ts) still builds its parseOptions without defaultKind: "channel", meaning callers using the async resolution path (e.g., username-resolving sends) will still encounter the ambiguous-recipient throw for bare numeric IDs.

Confidence Score: 3/5

The PR partially fixes the issue but leaves the same ambiguous-recipient throw reachable through parseAndResolveRecipient, which was not updated.
The synchronous parseRecipient path is correctly fixed, and the delivery-queue.ts safety net is sound. However, parseAndResolveRecipient — the async counterpart used for username-resolved sends — still builds parseOptions without defaultKind, so bare numeric IDs through that path will still throw and accumulate in the delivery queue. The fix is incomplete, reducing confidence in full resolution of the stated problem.
src/discord/send.shared.ts — specifically parseAndResolveRecipient at lines 88–90, which needs the same defaultKind: "channel" addition applied to parseRecipient.

_{Last reviewed commit: 64f52ff}

greptile-apps

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-03-01T01:28:39Z

Additional Comments (1)

src/discord/send.shared.ts
parseAndResolveRecipient still throws for bare numeric IDs

The fix adds defaultKind: "channel" to the synchronous parseRecipient, but the async parseAndResolveRecipient (used for programmatic/username-resolved sends) builds its parseOptions without defaultKind. Tracing through resolveDiscordTarget in targets.ts:

For a bare numeric ID like "1466624220632059934", safeParseDiscordTarget swallows the throw and returns undefined.
isLikelyUsername returns false (the regex /[\d]+$/ matches pure numeric strings).
shouldLookup is false.
The function reaches return directParse ?? parseDiscordTarget(trimmed, parseOptions), where directParse is undefined, so it calls parseDiscordTarget with no defaultKind — which throws the ambiguous error.

Any caller that routes through parseAndResolveRecipient will still hit the retry-loop bug. The fix should be applied here as well:

  const parseOptions = {
    defaultKind: "channel" as const,
    ambiguousMessage: `Ambiguous Discord recipient "${trimmed}". Use "user:${trimmed}" for DMs or "channel:${trimmed}" for channel messages.`,
  };

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/discord/send.shared.ts
Line: 88-90

Comment:
**`parseAndResolveRecipient` still throws for bare numeric IDs**

The fix adds `defaultKind: "channel"` to the synchronous `parseRecipient`, but the async `parseAndResolveRecipient` (used for programmatic/username-resolved sends) builds its `parseOptions` without `defaultKind`. Tracing through `resolveDiscordTarget` in `targets.ts`:

1. For a bare numeric ID like `"1466624220632059934"`, `safeParseDiscordTarget` swallows the throw and returns `undefined`.
2. `isLikelyUsername` returns `false` (the regex `/[\d]+$/` matches pure numeric strings).
3. `shouldLookup` is `false`.
4. The function reaches `return directParse ?? parseDiscordTarget(trimmed, parseOptions)`, where `directParse` is `undefined`, so it calls `parseDiscordTarget` with **no `defaultKind`** — which **throws** the ambiguous error.

Any caller that routes through `parseAndResolveRecipient` will still hit the retry-loop bug. The fix should be applied here as well:

```suggestion
  const parseOptions = {
    defaultKind: "channel" as const,
    ambiguousMessage: `Ambiguous Discord recipient "${trimmed}". Use "user:${trimmed}" for DMs or "channel:${trimmed}" for channel messages.`,
  };
```

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

…sync path

jini92 · 2026-03-01T03:02:16Z

Good catch - applied the same defaultKind=channel fix to parseAndResolveRecipient (async path) as well. Pushed in 8f3a979.

thewilloftheshadow · 2026-03-03T15:03:07Z

Superseded by #33142 which consolidates the fixes from this PR. Closing this in favor of that PR.

openclaw-barnacle bot added channel: discord Channel integration: discord size: XS labels Mar 1, 2026

chatgpt-codex-connector bot reviewed Mar 1, 2026

View reviewed changes

greptile-apps bot reviewed Mar 1, 2026

View reviewed changes

fix(discord): apply defaultKind=channel to parseAndResolveRecipient a…

8f3a979

…sync path

thewilloftheshadow mentioned this pull request Mar 3, 2026

fix(discord): harden channel resolution #33142

Merged

18 tasks

thewilloftheshadow closed this Mar 3, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(discord): default bare numeric IDs to channel kind, classify ambiguous recipient as permanent error#30198

fix(discord): default bare numeric IDs to channel kind, classify ambiguous recipient as permanent error#30198
jini92 wants to merge 2 commits intoopenclaw:mainfrom
jini92:fix/discord-ambiguous-recipient

jini92 commented Mar 1, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

chatgpt-codex-connector bot Mar 1, 2026

Uh oh!

greptile-apps bot commented Mar 1, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot commented Mar 1, 2026

Uh oh!

jini92 commented Mar 1, 2026

Uh oh!

thewilloftheshadow commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jini92 commented Mar 1, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (before fix)

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Mar 1, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Mar 1, 2026

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Mar 1, 2026

Uh oh!

jini92 commented Mar 1, 2026

Uh oh!

thewilloftheshadow commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants