* fix(telegram): clean up thread bindings to stale/failed ACP sessions on startup
When loading persisted thread bindings on manager creation, validate each
ACP session against the session store. Remove bindings where:
- Session entry doesn't exist (deleted externally)
- Session status is failed/killed/timeout
- ACP runtime state is 'error'
This addresses issue #60102 where Telegram DMs remained routed to stale
ACP sessions even after restart, because the binding file persisted
across restarts without validating the target session was still valid.
* fix(telegram): guard against null session entry and transient store read failures
Address review comments on PR #67822:
1. Skip bindings when readAcpSessionEntry returns null or when
session store is temporarily unreadable (storeReadFailed: true).
Without this, a transient I/O error would mark all ACP bindings
as stale and delete them on every startup.
2. Only set needsPersist when bindings were actually removed.
Previously, stale session keys from OTHER accounts could set
needsPersist=true even when zero bindings were removed for
the current account — causing spurious disk writes.
Also clean up redundant optional chaining on entry.status now
that we guard against undefined/nullable sessionEntry.
* perf(telegram): dedupe ACP session reads in startup cleanup
Cache readAcpSessionEntry calls by targetSessionKey. Multiple bindings
to the same ACP session now result in a single session store read instead
of one read per binding.
Addresses chatgpt-codex-connector P2 review comment on PR #67822.
* fix(telegram): skip non-ACP session keys in stale binding cleanup
Address chatgpt-codex-connector P1 review comment on PR #67822:
Plugin-bound Telegram conversations use "plugin-binding:*" keys
with targetKind === "acp", but these are NOT ACP runtime sessions.
readAcpSessionEntry() returns no entry for them, so !sessionEntry.entry
would classify them as stale and delete them on every startup.
Now checks isAcpSessionKey(binding.targetSessionKey) to skip plugin-bound
sessions from the stale session cleanup scan.
Also clarifies the comment to explain why we use targetKind === "acp"
// together with isAcpSessionKey() check.
* fix(telegram): import isAcpSessionKey from sessions/session-key-utils
isAcpSessionKey is not re-exported from openclaw/plugin-sdk/routing.
Fix import to use the correct subpath: openclaw/sessions/session-key-utils.
Addresses chatgpt-codex-connector P1 review comment on PR #67822.
* fix(telegram): import from relative path, remove unused variable
- Import isAcpSessionKey from relative path ../../sessions/session-key-utils.js
(not openclaw/sessions/session-key-utils which doesn't exist)
- Remove unused 'bindings' variable in for-of loop
Addresses CI failures on PR #67822.
* fix(telegram): export isAcpSessionKey from plugin-sdk/routing
isAcpSessionKey lives in src/routing/session-key.ts, which is already
exported via openclaw/plugin-sdk/routing. Re-export it from routing.ts
so extensions can import via the public plugin-sdk path.
Fixes chatgpt-codex-connector P1: relative path ../../sessions/session-key-utils.js
doesn't exist in the build output, making the Telegram extension fail
module resolution before startup cleanup can run.
* test(telegram): cover startup ACP binding cleanup
* fix: clear stale telegram ACP bindings on startup (#67822) (thanks @chinar-amrutkar)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
Remove the old qa-lab-runtime shim now that qa-runtime is the only live
consumer seam. This leaves one tiny shared runtime facade instead of two
parallel names for the same private helper surface.
Introduce a tiny generic qa-runtime seam for shared live-lane helpers and
repoint qa-matrix to it. This keeps the qa-lab host split while removing
the host-owned runtime name from runner code.
Drop the old qa-lab-runtime shim/export now that nothing consumes it and
keep the plugin-sdk surface aligned with the new seam.
Drop the generated qa-runner catalog and the missing/install placeholder
path for repo-private QA runners. The host should discover bundled QA
commands from manifest plus runtime surface only.
Also trim stale qa-matrix install docs and package metadata so the
source-only QA policy stays consistent.
* fix: sendPolicy deny suppresses delivery, not inbound processing (#53328)
Previously, sendPolicy "deny" returned early before the agent dispatch,
preventing the agent from ever seeing the message. This broke the use
case of an agent listening on WhatsApp groups with sendPolicy: deny to
read messages without replying — the agent couldn't read them at all.
Move the deny gate from before the agent dispatch to after it. The agent
now processes inbound messages normally (context, memory, tool calls),
but all outbound delivery paths are suppressed: final replies, tool
results, block replies, working status, plan updates, typing indicators,
and TTS payloads.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: propagate sendPolicy to ACP tail dispatch instead of hardcoded allow
The ACP tail dispatch path (ctx.AcpDispatchTailAfterReset) was passing
sendPolicy: "allow" unconditionally, which would bypass delivery
suppression in a /reset <tail> turn when the session has sendPolicy deny.
Pass through the resolved sendPolicy so the tail dispatch respects it.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: guard before_dispatch hook and ACP tail dispatch under sendPolicy deny
before_dispatch handled replies were leaking through sendFinalPayload
before the suppressDelivery guard was checked. ACP tail dispatch (from
/new <tail>) was being rejected by acp-runtime.ts deny checks instead
of proceeding with delivery suppression handled downstream.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* auto-reply: propagate deny suppression to reply_dispatch
* fix(acp): suppress onReplyStart when user delivery is denied
When sendPolicy resolves to "deny", ACP tail dispatch still invoked
onReplyStart via startReplyLifecycle before the suppressUserDelivery
check. Channels wire onReplyStart to typing indicators, so deny-scoped
sessions could still emit outbound typing events on /reset <tail>
flows and command bypass paths.
Gate startReplyLifecycleOnce on suppressUserDelivery so the lifecycle
is marked started but the callback is skipped. Payload delivery was
already suppressed; this closes the typing-indicator leak flagged by
Codex review (PR #65461 P1/P2).
* fix(acp): route non-tail deny turns through ACP when suppression is wired
tryDispatchAcpReplyHook was returning early for non-tail, non-command ACP
turns under sendPolicy: "deny", causing ACP-bound sessions to fall back
to the embedded reply path instead of flowing through acpManager.runTurn.
That diverged ACP session state, tool calls, and memory whenever
delivery suppression was active.
Now the early-return only fires when sendPolicy is "deny" AND the event
lacks suppressUserDelivery — i.e., when downstream delivery suppression
is not wired up. When suppressUserDelivery is set, dispatch-acp-delivery
already drops outbound sends (see onReplyStart / deliver guards), so ACP
can safely run the turn with state consistency preserved.
Existing behavior preserved:
- Command bypass still overrides deny
- Tail dispatch still overrides deny
- Plain-text deny turns without suppression still short-circuit
Addresses Codex bot P1 feedback on #65461.
* fix: gate empty-body typing indicator behind suppressTyping (#53328)
* fix: guard plugin-binding + fast-abort outbound paths under sendPolicy deny
The original PR computed suppressDelivery inside the try block, which was
after two outbound paths:
1. The plugin-owned binding block (sendBindingNotice calls for
unavailable/declined/error outcomes, plus the plugin's own "handled"
outcome) ran before the suppressDelivery flag existed, so plugin
notices still leaked under deny.
2. The fast-abort path dispatched "Agent was aborted." via
routeReplyToOriginating / sendFinalReply before the flag existed.
Move resolveSendPolicy() above the plugin-binding block so suppressDelivery
covers every outbound path downstream, matching the PR description's claim
that "all outbound paths are guarded by the flag."
Plugin-bound inbound handling under deny: plugin handlers can emit
outbound replies we cannot rewind, so skip the claim hook entirely under
deny and fall through to normal (suppressed) agent processing.
touchConversationBindingRecord still runs so binding activity stays
tracked.
Fast-abort under deny: still run the abort and record the completed
state, just don't emit the abort reply.
Tests:
- suppresses the fast-abort reply under sendPolicy deny
- delivers the fast-abort reply normally when sendPolicy is allow
(regression guard)
- skips plugin-bound claim hook under deny and falls through to
suppressed agent dispatch
Addresses Codex review findings on PR #65461.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Lobster <lobster@shahine.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
