When a newer inbound message arrives while an older dispatch is still
processing, buffered final answers from the old dispatch could be
delivered into the new message's thread.
Add `bufferedGeneration` to `BufferedFinalAnswer` to track which
abort fence generation buffered the answer. `takeBufferedFinalAnswer`
now rejects buffered answers whose generation doesn't match the
current dispatch's generation, preventing stale content delivery.
Fixes#76642
* fix(discord): normalize whitespace in command description comparison
Discord server-side storage collapses consecutive whitespace and removes
whitespace between adjacent CJK characters when persisting slash-command
descriptions. Our locally-serialized desired descriptors keep the original
whitespace, so commandsEqual returned false on every startup for any
deployment with multi-line or CJK-heavy descriptions.
This caused reconcile to issue a PATCH for every such command on every
gateway restart. Under Discord's per-application rate limit that quickly
produced a burst of 429s and some commands silently failed to register
until the next restart — a recurring symptom behind several Discord deploy
429 reports (#75341, #75888).
Fix: apply the same two normalizations to description strings in
comparableCommand — collapse runs of whitespace to a single space, then
drop whitespace between CJK boundary characters — before JSON-based
equality. This mirrors Discord's storage semantics so round-tripped
descriptions compare equal.
Adds command-deploy.test.ts with regression coverage for:
- server-side default fields ignored (dm_permission, nsfw, version, ids)
- required:false treated as absent (existing behavior)
- CJK descriptions with \n separators normalized
- mixed CJK/ASCII descriptions with consecutive whitespace
- substantive description diffs still flagged
- ASCII whitespace normalization
* fix(discord): normalize localized command descriptions
* fix(discord): ignore null localization maps in command reconcile
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Summary:
- Adds an OpenCode provider-policy public artifact that delegates Claude thinking profiles, plus regression tests and a changelog entry for preserving `xhigh` on `opencode/claude-opus-4-7`.
- Reproducibility: yes. Source inspection on current main shows the model-switch path remaps unsupported store ... vider-policy-api` artifact for the fallback resolver; the proposed test exercises that stored-`xhigh` path.
Automerge notes:
- No ClawSweeper repair was needed after automerge opt-in.
Validation:
- ClawSweeper review passed for head efa152cca5.
- Required merge gates passed before the squash merge.
Prepared head SHA: efa152cca5
Review: https://github.com/openclaw/openclaw/pull/76760#issuecomment-4366483080
Co-authored-by: mkdev11 <MkDev11@users.noreply.github.com>
Summary:
- The branch changes Telegram polling startup to reuse the successful probe `getMe` result as grammY `botInfo` ... es` after recoverable `deleteWebhook` failures, and updates Telegram docs, changelog, and regression tests.
- Reproducibility: yes. for the narrow PR bug: source inspection shows current main can block before polling o ... d timeout coverage that reaches `run()`. The full linked high-RTT report remains only partially reproduced.
Automerge notes:
- Ran the ClawSweeper repair loop before final review.
- Included post-review commit in the final squash: fix(telegram): start polling after webhook cleanup timeout
- Included post-review commit in the final squash: fix(telegram): extract bot info contract
Validation:
- ClawSweeper review passed for head c74bbdd1ff.
- Required merge gates passed before the squash merge.
Prepared head SHA: c74bbdd1ff
Review: https://github.com/openclaw/openclaw/pull/76735#issuecomment-4366417178
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Per-chat sequential queue had no timeout: if a single dispatch hung
(e.g. an agent call that never resolved), every subsequent message in
the same chat stayed `queued` until the gateway was restarted.
Add an optional `taskTimeoutMs` (default 5 min) to `createSequentialQueue`.
After the cap, the in-flight task is evicted from the blocking chain so
newer same-key tasks can proceed. The original task is NOT aborted —
it continues running in the background; we just stop starving the queue.
A warning log surfaces the eviction with the offending key.
`taskTimeoutMs: 0` restores legacy unbounded behavior.
Same-chat FIFO ordering for normal-cadence messages is preserved
(see #64324) — only pathologically slow tasks get evicted.
Fixes#70133.
