* fix(discord): guard progress draft collapse to prevent re-collapse on cleaned stream
Commit 86ea382 added a progressDraftStartedBeforeFinal latch that snapshots
hasStarted at markFinalReplyStarted time. This correctly preserves collapse
eligibility when an abort cancels the compositor gate before
shouldCollapseProgressDraft runs.
However the latch was never cleared. After markPreviewFinalized turned the
draft into a summary, hasProgressDraftStarted remained true permanently. In
multi-tool turns with multiple final-payload deliveries, this caused
shouldCollapseProgressDraft to re-trigger collapse on an already-cleaned or
sealed draft stream, corrupting downstream delivery state and causing tool
results to render as image content blocks instead of text.
Fix: add a progressDraftCollapsed guard set by markPreviewFinalized that
prevents hasProgressDraftStarted from returning true after the draft has been
collapsed into a summary. Reset the guard on handleAssistantMessageBoundary
so followup/queued turns start fresh.
Per Discord channel session, all tool results rendered as image content
blocks. Model received (see attached image) placeholders instead of text.
Fixes#100782
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(discord): use valid table/chunk mode literals in collapse-guard tests
* test(discord): add abort-race gate-cancellation latch survival test
* fix(discord): consume progress draft collapse once
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* fix(discord): retain progress receipt on retry
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* fix(discord): rearm queued progress drafts
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* test(discord): assert progress lifecycle outcomes
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* fix(discord): reset queued progress turn state
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* test(discord): model recreated progress drafts
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* fix(discord): serialize progress draft rotation
Co-authored-by: xialonglee <li.xialong@xydigit.com>
* fix(discord): isolate queued draft generations
Co-authored-by: Peter Lee <xialonglee@users.noreply.github.com>
* test(discord): align synchronous draft rotation
Co-authored-by: Peter Lee <xialonglee@users.noreply.github.com>
* fix(discord): distinguish draft rotation ownership
Co-authored-by: Peter Lee <xialonglee@users.noreply.github.com>
* chore: keep release notes in pull request
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): stop retrying non-idempotent sends on post-connect-ambiguous errors
Discord's outbound retry runner treated every transient transport error as
retryable, including ECONNRESET, ETIMEDOUT, AbortError, and the undici
headers/body/socket timeouts. Those errors can fire after Discord has already
received and created the message but before the client reads the response, so
replaying the non-idempotent createChannelMessage POST delivers the same
message twice while reporting success.
Add a pre-connect-only classifier (isRetryableDiscordPreConnectError) covering
errors that provably never reached Discord (DNS/connect refused/connect
timeout) plus rate-limit rejections, mirroring the Telegram send-path
carve-out. The retry runner now accepts a per-call nonIdempotent option; the
message-create and thread-create call sites opt in so ambiguous post-connect
errors surface to the caller instead of double-sending. Idempotent REST calls
(reactions, edits, DM-channel lookup, uploads) keep the broader transient set.
* fix(discord): retry nonce-enforced message creates
* fix(discord): scope create retries by endpoint
* fix(discord): stabilize sticker and poll create nonce across retries
* fix(discord): tighten create retry safety
* fix(discord): preserve nonce-safe retries
* fix(discord): scope nonce fields to message creates
* test(discord): cover nonce-safe direct sends
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(logs): clean up gateway and channel startup/shutdown log output
Scope Discord slash-command deploy REST diagnostics to command routes so
concurrent startup traffic (voice-state probes, channel lookups) keeps its
owner's error handling; make per-request deploy error lines verbose-only and
drop JSON bodies that only repeat message+code. Log allowlist summaries one
line per call so unresolved lines keep their timestamp/subsystem prefix, and
skip identity lookups that resolved to themselves. Remove embedded subsystem
prefixes, demote routine signal/shutdown/force/postbuild/diag chatter to
debug or verbose, merge the duplicate Control UI build notices, drop doctor's
duplicate backup line, and name the config surface or platform limit in the
transcripts autoStart and command-limit warnings.
Fixes#104163
* fix(slack): keep bare-name allowlist resolutions in startup log summary
Only omit identity lookups where the input already is the resolved id;
name-based lookups that translated to an id stay logged even when the
display name matches the input.
* fix(telegram): keep isolated-ingress readiness marker on the runtime log
test/e2e/qa-lab telegram-bot-token-runtime waits for this line via the
injected RuntimeEnv.log; verbose-only logging would deterministically time
out that live proof. Comment the contract at the call site.
* fix(discord): keep thread-binding persona UTF-16 safe
resolveThreadBindingPersona truncated the persona label with a raw .slice(0, THREAD_BINDING_PERSONA_MAX_CHARS). When an emoji or other astral code point straddles the 80-unit limit, the raw slice keeps a dangling high surrogate, so the Discord thread-binding persona (webhook display name) can carry a lone surrogate. Route the clamp through the shared truncateUtf16Safe primitive so the boundary code point is dropped whole. Adds a regression test.
* test(discord): assert exact persona boundary
* docs(changelog): credit Discord persona fix
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* feat(channels): narrated progress drafts + activity receipt on the final answer
Progress mode replaces raw tool lines with short utility-model narration of
what the agent is doing (streaming.progress.narration, default on, requires
an explicit utilityModel). On Discord the final answer now carries the
-# activity receipt and the working draft is deleted once the answer lands,
so busy channels keep no orphaned tool log above the reply.
Formatting verified remotely via Testbox oxfmt --check (hook bypassed:
no node_modules in this worktree).
* fix(channels): keep narration toggle independent of channel-default stream mode
Discord resolves its own progress default, so the resolver must not re-derive
mode with the generic partial fallback (narration was off for unset config).
* fix(auto-reply): honor status-only command text in narration model input
streaming.progress.commandText: "status" hides raw exec/bash text from the
channel draft; narration input now mirrors that policy so the utility model
never receives more command detail than the draft shows (Codex review P2).
Formatting verified remotely via Testbox oxfmt --check.
* fix(auto-reply): share the draft's command-tool set for narration and regen channel metadata
Reuse isCommandToolName (exec|shell|bash) so narration's commandText policy
matches the draft formatter exactly, and regenerate bundled channel config
metadata for the new streaming.progress.narration key (Codex review round 2).
Gates verified on Testbox: config:channels:check, oxfmt --check, 4 test shards.
* fix(channels): clear stale narration when the narrator stops mid-turn
An empty narration update now falls the draft back to raw tool lines, and the
narrator emits that clear when it disables after consecutive failures or the
per-turn cap, so drafts never pin stale status text (Codex review round 3).
Gates verified on Testbox: oxfmt --check + 4 test shards.
* chore(config): regen bundled channel metadata after rebase onto main
* chore: CI fixups — lint nits, test harness types, docs map, SDK surface budget
Two deliberate public SDK additions (resolveChannelStreamingProgressNarration,
isCommandToolName via the streaming wildcard re-export) bump the pinned
public-surface budgets to current counts (exports 10488, callable 5235).
Gates verified on Testbox: oxfmt, targeted oxlint, docs:map:check,
config:channels:check, check:test-types, 5 test shards.
Carry typed forum/media parent metadata through the message-send path so implicit thread creation uses the configured default archive duration.
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): add timeouts to voice upload requests
* fix(discord): refine voice upload timeouts
Use the normalized REST timeout for upload negotiation and the existing attachment transfer budget for the signed audio upload. Reuse the shared loopback test harness and verify both hanging sockets close.
Thanks @Alix-007 for the original timeout fix.
Co-authored-by: llagy009 <0668001470@xydigit.com>
---------
Co-authored-by: llagy009 <0668001470@xydigit.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): use truncateUtf16Safe for deploy error body truncation
* test(discord): cover utf16 deploy errors
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): drain queued outbound deliveries after gateway reconnect (#56610)
Discord sends that failed while the gateway websocket was reconnecting
(close codes 1005/1006) stayed stuck in the outbound delivery queue and
were silently dropped. Classify sends that fail while the registered
gateway is disconnected as retryable, and drain pending discord queue
entries when the gateway reconnects, matching the WhatsApp/Telegram
reconnect drains.
* fix(discord): harden reconnect recovery
Co-authored-by: tiffanychum <71036662+tiffanychum@users.noreply.github.com>
* refactor(discord): remove unsafe reconnect replay
* fix(discord): bound reconnect retry per request
Co-authored-by: tiffanychum <71036662+tiffanychum@users.noreply.github.com>
* chore(changelog): leave reconnect fix to release flow
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): download attachments at receipt time, not after the run queue
Discord's CDN attachment URLs carry an expiring `ex` TTL. Media was
downloaded in processDiscordMessageInner, after the inbound run queue,
so messages delayed behind a busy run lost their attachments silently.
Resolve attachments/forwarded media during preflightDiscordMessage
instead, before the message is enqueued, and carry the result forward
on the context for process to reuse.
Fixes#96165
* refactor(discord): carry one prepared media snapshot
Co-authored-by: ZacharyYW <zachary.w.yuan123@gmail.com>
* fix(discord): guard bot media before download
* chore(discord): leave release notes to release flow
* docs(changelog): credit Discord attachment fix
* chore(changelog): leave attachment fix to release flow
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): bound gateway metadata response body reads to prevent OOM
The materializeGuardedResponse helper in the Discord gateway metadata path
buffered the full upstream Response body via response.arrayBuffer() without
any size cap. A malicious or malfunctioning /gateway/bot endpoint that returns
an oversized payload could exhaust gateway memory.
Replace arrayBuffer() with readResponseWithLimit(4 MiB), consistent with
DISCORD_API_RESPONSE_BODY_LIMIT_BYTES in api.ts. Overflow throws an Error
with the byte counts.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(discord): wrap readResponseWithLimit result in Uint8Array for type compat
readResponseWithLimit returns Buffer which is not assignable to BodyInit in
the undici Response constructor type. Wrap in new Uint8Array() to satisfy the
boundary dts check. Also remove testExports export and mock fetchWithSsrFGuard
in tests via vi.hoisted + vi.mock to avoid leaking internal test-only exports.
Co-Authored-By: Claude <noreply@anthropic.com>
* test(discord): tighten gateway metadata proof
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): use configured statusReactions.timing instead of DEFAULT_TIMING
Makes the Discord message finalizer respect user-configured
doneHoldMs/errorHoldMs instead of always using hardcoded
DEFAULT_TIMING values. Brings Discord to parity with Telegram
and Slack which already use configured timing.
Fixes#78431
* test(discord): strengthen configured-timing regression with old-default assertion
Add a no-cleanup assertion at DEFAULT_TIMING.doneHoldMs (1500ms) before
advancing to the configured 2000ms hold, so the test fails against the
old hardcoded-default behavior. Add a matching errorHoldMs regression
test using failedCounts to drive the error terminal path.
Address ClawSweeper [P2] review finding on #94736: the previous test
advanced straight to 2000ms and would pass without the runtime fix
because main already removes the done reaction at 1500ms.
* refactor(discord): unify status reaction timing proof
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(discord): handle ffmpeg stderr stream errors in voice playback
createDiscordOpusPlaybackStream guards ffmpeg stdout and stdin against raw
stream 'error' events (an unhandled stream error throws and crashes the
gateway via uncaughtException), but the stderr stream on the same child was
left unguarded. Add the symmetric stderr error handler, routing it through
opusStream.destroy like stdout. Add a regression test covering stdout and
stderr stream errors.
* refactor(discord): unify ffmpeg stream errors
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
