Root cause of the plugin not loading was a symlink
~/.openclaw/extensions/openclaw-multi-session-plugins -> /tmp/... (ephemeral).
Replaced with a real dir, registered via `openclaw plugins install --force`,
restarted the gateway: now boots with "6 plugins ... openclaw-multi-session-plugins"
from the stable path, provenance warning gone, and xworkmate.session.prepare returns
the real plugin mapping (no bridge fallback). Survives restart.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rewrites the timeline (§1) and topology (§2) as the correct FOUR-layer chain
App → bridge → openclaw-multi-session-plugins → OpenClaw gateway, and documents the
plugin's multi-session/multi-thread role: session mapping (appThreadKey⇄openclawSessionKey),
per-(session,run) artifactScope = tasks/<sanitize(sessionKey)>/<runId>, the strict
sessionKey/runId/artifactScope triplet validation, and the expectedArtifactDirs
workspace-root fallback scan.
Live-verified against 127.0.0.1:8787 (plugin loaded, commit 2333c3e):
- session.prepare returns a real mapping; chat.send returns runId; xworkmate.tasks.get
is handled by the plugin but returns no_native_task_record with an empty task scope
(chain reaches the plugin layer; the agent run produced no queryable task / no file —
a layer-4 execution/landing issue).
Adds §7 stability improvements grounded in this live run:
- S0 install the plugin from a stable path (not /private/tmp) — the primary reliability fix.
- S1 expectedArtifactDirs was [] → the plugin's workspace-root fallback is inert; bridge
should always pass default dirs (reports/, artifacts/).
- S2 no_native_task_record status ambiguity (running vs completed-without-artifact).
- S3 sessionKey/runId/artifactScope triplet consistency (don't pre-prefix agent:main:).
- S4 runtime observability across all four layers.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live verification disproved the earlier "xworkmate.* protocol namespace drift"
conclusion. The xworkmate.* gateway methods are REAL — registered at runtime by
the openclaw-multi-session-plugins plugin (index.ts registerGatewayMethod). The
actual failure: the running OpenClaw gateway did not load that plugin because its
source path was the ephemeral /private/tmp/openclaw-multi-session-plugins/... and
the gateway booted (09:21) ~9h before those files were populated (18:40), so it
started with 5 plugins (no multi-session) and every xworkmate.* returned
"unknown method". Restarting the gateway loads 6 plugins and the methods work
(errors shift to plugin-level param validation).
Changes:
- Add a corrected conclusion banner up top distinguishing the primary root cause
(plugin load) from the T1-T9 robustness hardening.
- Replace the wrong "protocol drift / native alignment" section with the
plugin-not-loaded root cause + evidence + the abandoned-branch note
(fix/gateway-task-protocol-alignment must NOT be merged).
- Fix failure-row 10, T13 (runtime-state check now covers gateway plugin load),
and the landing-order to put the plugin fix as step 0.
- Cross-reference openclaw-gateway-e2e-regression/ROOT_CAUSE_ANALYSIS.md (which
was already correct about the 4-layer chain).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds the 2026-06-26 decisive finding: the bridge forwards `xworkmate.*` method
names the OpenClaw 2026.6.2 gateway does not implement (it uses native
tasks.get/list/cancel and artifacts.list/get/download). Documents the corrected
end-to-end turn timeline with the three break points (tasks.get unknown method;
{taskId}-only param shape + taskId!=runId; artifacts.* drift blocking .md delivery),
the evidence (gateway source + schema + CHANGELOG), the implemented task-lifecycle
fix, and the precisely-specified remaining work (artifact-method alignment + test
fixture migration). Corrects the earlier (wrong) "push/pull mismatch" conclusion.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Records the durable per-session run-registry implementation (bridge branch
fix/gateway-durable-run-registry): T7 gateway-unconfirmed fallback, T8 terminal
result cache, T9 DeadlineAt interrupt — with the trade-offs (no gatewayruntime
pending-map rewrite; per-session in-memory store not yet cross-restart durable;
T9 only force-terminates when the gateway is unconfirmed) and the test names that
cover each.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Symptom: a gateway turn shows "任务运行中..." forever and 停止 has no effect,
even though the OpenClaw gateway has already finished (ACP_HTTP_CONNECTION_CLOSED).
- T3: add a hard deadline to the running-handle poll branch so the client no
longer polls forever when tasks.get keeps returning "running". Budget is
derived from taskLoadClass (10/30/60min, aligned with the bridge) + grace;
on timeout the turn lands in a recoverable `interrupted` state
(OPENCLAW_RUN_POLL_TIMEOUT) prompting the user to resend.
- T4: make 停止 locally authoritative — capture the association, mark the turn
aborted immediately (clears pending, exits the poll loop), then fire
tasks.cancel best-effort so a hung/failed cancel RPC can't block termination.
- T6: applyGatewayChatFailureInternal now authoritatively clears the pending
flag (both raw + normalized key). Previously runOpenClawGatewayQueuedTurnInternal's
finally never cleared it, leaving "error shown but still running".
Full cross-repo analysis + remaining TODO in docs/cases/06.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
