fix(outbound): keep Discord runtime adapters resolvable by TurboTheTurtle · Pull Request #90198 · openclaw/openclaw

TurboTheTurtle · 2026-06-04T06:24:58Z

Summary

What problem does this PR solve?

Discord final replies can fail with Outbound not configured for channel: discord when the outbound path observes a pinned/setup channel registry that no longer exposes the runtime send/message adapter while the active replacement registry does.
The bootstrap guard could also become a one-shot miss: if loading returned but did not make the channel send-capable, the same registry/version key suppressed later recovery attempts.

Why does this matter now?

Issue [Bug]: Discord final replies can still lose outbound adapter on 2026.6.1 #90162 reports the final reply delivery failure on v2026.6.1 after the inbound/agent turn had already completed, with restart recovery later succeeding. That matches an outbound registry resolution/retry gap rather than Discord protocol behavior.

What is the intended outcome?

Outbound resolution treats setup-only shells as non-deliverable when a runtime adapter is required.
Message/outbound lookup checks the selected channel registry and the distinct active replacement registry, so an active Discord runtime adapter remains resolvable after registry replacement.
Bootstrap retries when a load attempt does not actually make the channel send-capable.

What is intentionally out of scope?

Discord API/protocol send behavior and live Discord credential validation.
Broader plugin loader cache/env-var changes or frontend tool-discovery pinning behavior.

What does success look like?

Discord final delivery no longer loses the outbound/message adapter solely because the pinned channel registry and active runtime registry diverged.

What should reviewers focus on?

Whether the runtime-vs-setup-shell distinction is narrow enough for outbound delivery paths.
Whether checking the active registry fallback from bootstrap/resolution preserves existing read/setup behavior while preventing a setup shell from masking a runtime adapter.

Linked context

Which issue does this close?

Closes #90162

Which issues, PRs, or discussions are related?

Related #87333 (adjacent channel-registry pinning issue; different files and failure path).

Was this requested by a maintainer or owner?

No maintainer request seen; ClawSweeper marked the issue source-repro/fix-shape-clear.

Real behavior proof (required for external PRs)

Behavior or issue addressed:
Discord final reply delivery could fail with Outbound not configured for channel: discord after active registry replacement when the selected channel registry still exposed only a setup shell and the bootstrap attempt guard did not retry after a non-send-capable load.
Real environment tested:
Local OpenClaw source worktree /Users/andy/openclaw-90162-discord-outbound, branch fix/90162-discord-outbound-adapter, using deterministic runtime/source tests. Live Discord proof was also captured on a PR-head temp gateway running OpenClaw 2026.6.2 (f62c3e0) with build-info commit f62c3e0912ee0a7aebe5db4910f7ec2ecd57781b; the temp PR-head gateway was stopped afterward and production gateway health was verified OK.
Exact steps or command run after this patch:
node scripts/run-vitest.mjs run src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts src/plugins/runtime.channel-pin.test.ts

node scripts/run-vitest.mjs src/infra/outbound/deliver.test.ts src/infra/outbound/delivery-queue.recovery.test.ts src/infra/outbound/message-action-runner.plugin-dispatch.test.ts src/infra/outbound/message-action-runner.media.test.ts src/infra/outbound/channel-selection.test.ts src/infra/outbound/targets.test.ts

node scripts/run-vitest.mjs src/infra/outbound/message.test.ts src/cron/isolated-agent/delivery-target.test.ts src/gateway/server-methods/send.test.ts src/channels/turn/durable-delivery.test.ts

pnpm exec oxfmt --check src/infra/outbound/channel-bootstrap.runtime.test.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-resolution.ts

node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/infra/outbound/channel-bootstrap.runtime.test.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-resolution.ts

node scripts/run-tsgo.mjs -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfo

node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo

git diff --check

codex review --base upstream/main

Live Discord proof commands/checks:

git -C <pr-worktree> rev-parse HEAD

node <pr-worktree>/dist/index.js --version

jq . <pr-worktree>/dist/build-info.json

Started PR-head gateway on temp port 18790 with temp config and Discord tech account enabled.

gateway health --json against temp port.

Sent a real Discord trigger message in #agent-chat from another bot account.

Read recent Discord messages through the Discord API.

rg "Outbound not configured for channel: discord" <pr-head-log>
Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

Live Discord proof environment:
PR: https://github.com/openclaw/openclaw/pull/90198
Issue: #90162
Head SHA: f62c3e0912ee0a7aebe5db4910f7ec2ecd57781b
Build: OpenClaw 2026.6.2 (f62c3e0)
build-info: version=2026.6.2 commit=f62c3e0912ee0a7aebe5db4910f7ec2ecd57781b builtAt=2026-06-04T07:27:06.943Z

Redacted live Discord proof log:
2026-06-04T00:48:14.163-07:00 [gateway] loading configuration...
2026-06-04T00:48:16.594-07:00 [gateway] http server listening (... discord ...)
2026-06-04T00:48:16.609-07:00 [discord] [tech] starting provider
2026-06-04T00:48:17.360-07:00 [gateway] ready
2026-06-04T00:48:18.174-07:00 [discord] [tech] Discord bot probe resolved @CTO
2026-06-04T00:48:18.778-07:00 discord gateway: Gateway websocket opened

2026-06-04T00:51:53.947-07:00 discord: inbound id=<message-id> guild=<guild-id> channel=<channel-id> mention=yes type=guild content=yes
2026-06-04T00:51:53.956-07:00 [discord-preflight] success: route=tech sessionKey=<session-key>
2026-06-04T00:51:54.064-07:00 [diagnostic] message received: channel=discord chatId=channel:<channel-id> messageId=<message-id> sessionKey=<session-key>
2026-06-04T00:51:54.810-07:00 [diagnostic] session turn created: runId=<run-id> sessionId=<session-id> sessionKey=<session-key> agentId=tech channel=discord trigger=user
2026-06-04T00:51:58.702-07:00 [diagnostic] session state: sessionId=<session-id> sessionKey=<session-key> prev=processing new=idle reason="run_completed"
2026-06-04T00:51:59.101-07:00 [diagnostic] message dispatch completed: channel=discord sessionKey=<session-key> outcome=completed duration=4558ms
2026-06-04T00:51:59.101-07:00 [diagnostic] message processed: channel=discord chatId=channel:<channel-id> messageId=<message-id> outcome=completed duration=5036ms
2026-06-04T00:52:01.058-07:00 discord: delivered 1 reply to channel:<channel-id>

Discord API readback:
2026-06-04T07:51:53.747000+00:00 author=ATLAS id=<message-id> content="<@CTO> PR90198_PROOF_TRIGGER_20260604T0055Z ..."
2026-06-04T07:51:59.006000+00:00 author=CTO id=<message-id> content="PR90198_PROOF_OK_20260604T0055Z"

Error check:
no Outbound-not-configured error found in PR-head log

[test] passed 2 Vitest shards in 8.37s
# channel-resolution + channel-bootstrap + runtime.channel-pin: 21 infra tests, 14 plugin tests

[test] passed 1 Vitest shard in 6.50s
# nearby outbound sweep: 6 files, 252 tests

[test] passed 4 Vitest shards in 17.07s
# gateway/infra/cron/channels consumer sweep: 2 gateway files/112 tests, 1 infra file/11 tests, 1 cron file/53 tests, 1 channels file/6 tests

All matched files use the correct format.

codex review --base upstream/main:
No actionable regressions were identified in the changed outbound channel bootstrap/resolution paths. The added behavior is covered by targeted tests, and nearby outbound/gateway tests passed.

Observed result after fix:
Source-backed runtime tests prove that setup-only and actions-only shells do not satisfy runtime outbound resolution, active replacement registries remain visible to message/outbound resolution, and bootstrap retries after a load that still does not make the channel send-capable. Live Discord proof also shows a real Discord inbound turn completed and the final outbound Discord reply posted successfully on PR fix(outbound): keep Discord runtime adapters resolvable #90198 / SHA f62c3e0912ee0a7aebe5db4910f7ec2ecd57781b with no Outbound not configured for channel: discord error in the PR-head log.
What was not tested:
A live before/after reproduction on the exact pre-patch SHA was not run; the before behavior is covered by the linked stable-release issue logs and source-level regression tests.
Proof limitations or environment constraints:
Live proof used a temporary PR-head gateway on port 18790 with a Discord tech account. Message, guild, channel, session, and run identifiers are redacted. The temp PR-head gateway was stopped after proof capture and production gateway health was verified OK.
Before evidence (optional but encouraged):
The added regression tests model the source-level failure shape from [Bug]: Discord final replies can still lose outbound adapter on 2026.6.1 #90162: pinned setup/channel registry plus active runtime replacement and a non-send-capable bootstrap result. These cases would have returned/kept a setup shell or suppressed retry before the resolver/bootstrap changes.

Tests and validation

Which commands did you run?

node scripts/run-vitest.mjs run src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts src/plugins/runtime.channel-pin.test.ts — passed
node scripts/run-vitest.mjs src/infra/outbound/deliver.test.ts src/infra/outbound/delivery-queue.recovery.test.ts src/infra/outbound/message-action-runner.plugin-dispatch.test.ts src/infra/outbound/message-action-runner.media.test.ts src/infra/outbound/channel-selection.test.ts src/infra/outbound/targets.test.ts — passed
node scripts/run-vitest.mjs src/infra/outbound/message.test.ts src/cron/isolated-agent/delivery-target.test.ts src/gateway/server-methods/send.test.ts src/channels/turn/durable-delivery.test.ts — passed
pnpm exec oxfmt --check src/infra/outbound/channel-bootstrap.runtime.test.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-resolution.ts — passed
node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/infra/outbound/channel-bootstrap.runtime.test.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-resolution.ts — passed
node scripts/run-tsgo.mjs -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfo — passed
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo — passed
git diff --check — passed
codex review --base upstream/main — no actionable regressions

What regression coverage was added or updated?

src/infra/outbound/channel-bootstrap.runtime.test.ts covers active replacement registry send-capability visibility and retry after a bootstrap attempt that leaves the channel non-send-capable.
src/infra/outbound/channel-resolution.test.ts covers pinned message adapter lookup after active registry replacement, setup shell and actions-only avoidance during bootstrap, active runtime preference over loaded setup shells, and non-return of setup shells after unsuccessful bootstrap.

What failed before this fix, if known?

A setup-only channel shell could be returned as the outbound plugin for a runtime delivery path, masking a send-capable active runtime plugin or leaving delivery to fail as unsupported.
Bootstrap could record an attempt even when the channel still could not send, suppressing a later retry in the same registry-version window.

If no test was added, why not?

Tests were added.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes. Final outbound delivery should now recover through a runtime adapter instead of failing when registry replacement leaves a setup shell in the selected channel registry.

Did config, environment, or migration behavior change? (Yes/No)

No.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No.

What is the highest-risk area?

Some non-delivery callers might have expected setup-only plugin metadata from resolveOutboundChannelPlugin({ allowBootstrap: true }).

How is that risk mitigated?

The stricter runtime-surface filtering applies to outbound/runtime resolution. Read-only resolver paths still preserve setup/metadata visibility, and targeted plus nearby consumer tests passed.

Current review state

What is the next action?

Ready for maintainer/ClawSweeper review.

What is still waiting on author, maintainer, CI, or external proof?

CI is green on the current SHA. ClawSweeper requested live Discord proof; redacted live proof has now been added to the PR body showing inbound Discord processing and final reply delivery on f62c3e0912ee0a7aebe5db4910f7ec2ecd57781b.

Which bot or reviewer comments were addressed?

No PR comments yet. The implementation follows the issue hint to prioritize registry/outbound adapter resolution over Discord protocol code.

TurboTheTurtle · 2026-06-04T06:25:13Z

@clawsweeper re-review

clawsweeper · 2026-06-04T06:25:15Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Failed
Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26934855891
Updated: 2026-06-04T06:26:52.354Z

TurboTheTurtle · 2026-06-04T06:27:05Z

@clawsweeper re-review

clawsweeper · 2026-06-04T06:27:07Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Superseded
Detail: A newer re-review for this item started before this run finished, so GitHub cancelled this older run. Check the latest ClawSweeper run for the current result.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26934932185
Updated: 2026-06-04T06:31:58.959Z

clawsweeper · 2026-06-04T06:29:26Z

Codex review: needs changes before merge. Reviewed June 7, 2026, 4:17 AM ET / 08:17 UTC.

Summary
The PR updates outbound channel bootstrap and resolution to consult active replacement registries, avoid setup/actions-only shells on delivery paths, retry non-send-capable bootstraps, and add regression tests.

PR surface: Source +98, Tests +223. Total +321 across 4 files.

Reproducibility: yes. for the remaining blocker: source inspection shows the PR-head resolver can return a metadata-only message object before checking the active send-capable registry, and the delivery handler then rejects it. I did not run tests because this was a read-only review.

Review metrics: none identified.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦞 diamond lobster
Patch quality: 🧂 unranked krab
Result: blocked by patch quality or review findings.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Fix delivery resolution so metadata-only message adapters do not mask active send-capable adapters.
[P2] Add the missing metadata-only setup-shell regression and rerun the focused outbound resolver/bootstrap tests.

Risk before merge

[P1] Merging now can still miss final replies for channel plugins whose selected setup shell has a metadata-only message object while the active replacement registry has the real message.send.text adapter.

Maintainer options:

Fix send-capable resolution before merge (recommended)
Make runtime delivery lookup skip message adapters without send.text, continue to the active replacement/bundled/bootstrap paths, and add the metadata-only setup-shell regression.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Repair the outbound resolver so delivery paths treat a message adapter as send-capable only when `message.send.text` exists, preserve read-only setup-shell lookup, add the metadata-only setup-shell plus active `message.send.text` regression, and run `node scripts/run-vitest.mjs src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts` plus `git diff --check`.

Next step before merge

[P2] Automerge is armed and the blocker is a narrow outbound resolver/test repair that automation can attempt on the PR branch.

Security
Cleared: The diff is limited to outbound runtime resolution and tests, with no dependency, workflow, secret, install, or supply-chain surface changes found.

Review findings

[P1] Skip metadata-only message adapters before returning — src/infra/outbound/channel-resolution.ts:287

Review details

Best possible solution:

Keep the PR branch but repair delivery resolution to require send-capable outbound/message surfaces, while preserving read-only setup-shell lookup behavior.

Do we have a high-confidence way to reproduce the issue?

Yes for the remaining blocker: source inspection shows the PR-head resolver can return a metadata-only message object before checking the active send-capable registry, and the delivery handler then rejects it. I did not run tests because this was a read-only review.

Is this the best way to solve the issue?

No. The PR is in the right layer and covers the live Discord path, but the send-path predicate needs to match the bootstrap send-capable contract before this is the best fix.

Full review comments:

[P1] Skip metadata-only message adapters before returning — src/infra/outbound/channel-resolution.ts:287
ChannelMessageAdapterShape allows message without send, but this path returns the first plugin.message from the selected/pinned registry and then short-circuits. If that setup shell only carries durable/live/receive metadata while the active replacement registry has message.send.text, createPluginHandler still sees no message.send.text or outbound.sendText and throws Outbound not configured, leaving the final-reply failure reachable. Please require a send-capable message adapter for delivery resolution and add that regression.
Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.91

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against a931884eb543.

Label changes

Label justifications:

P1: This PR targets a real Discord final-reply delivery regression and the remaining blocker can still suppress user-visible channel replies.
merge-risk: 🚨 message-delivery: The current patch can still route delivery through a non-send-capable message shell and fail final reply dispatch.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦞 diamond lobster and patch quality is 🧂 unranked krab.
status: 🚀 automerge armed: This PR is in ClawSweeper's automerge lane. Sufficient (logs): The PR body supplies redacted live Discord gateway logs and API readback showing after-fix inbound, completed agent turn, delivered final reply, and no outbound-not-configured error.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies redacted live Discord gateway logs and API readback showing after-fix inbound, completed agent turn, delivered final reply, and no outbound-not-configured error.

Evidence reviewed

PR surface:

Source +98, Tests +223. Total +321 across 4 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	123	25	+98
Tests	2	228	5	+223
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	4	351	30	+321

Acceptance criteria:

[P1] node scripts/run-vitest.mjs src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts.
[P1] node scripts/run-vitest.mjs src/infra/outbound/deliver.test.ts src/infra/outbound/delivery-queue.recovery.test.ts src/infra/outbound/message-action-runner.plugin-dispatch.test.ts.
[P1] node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.core.json src/infra/outbound/channel-resolution.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-bootstrap.runtime.test.ts.
[P1] git diff --check.

What I checked:

Repository policy read: Root AGENTS.md and scoped outbound/plugins AGENTS.md were read; the review applied the deep-review and plugin runtime boundary guidance. (AGENTS.md:1)
PR-head message resolution still accepts any message object: The PR-head resolver returns the first plugin.message from loaded/pinned/active/bundled registries and short-circuits when current is truthy, without checking message.send.text. (src/infra/outbound/channel-resolution.ts:287, 7799e5364216)
PR-head plugin predicate is broader than the send-capable bootstrap predicate: channelPluginHasRuntimeOutboundSurface treats any plugin.message as runtime outbound, while bootstrap's send-capable check requires outbound.sendText or message.send.text. (src/infra/outbound/channel-resolution.ts:135, 7799e5364216)
Message adapter contract permits metadata-only adapters: ChannelMessageAdapterShape has optional durableFinal, send, live, and receive fields, so a truthy message object does not guarantee send.text exists. (src/channels/message/types.ts:396, a931884eb543)
Final delivery still requires a real text sender: createChannelHandler throws Outbound not configured for channel when neither message.send.text nor outbound.sendText exists, so returning a metadata-only message adapter still fails delivery. (src/infra/outbound/deliver.ts:227, a931884eb543)
Regression tests miss the metadata-only message variant: PR-head tests cover send-capable message adapters and setup/actions-only shells, but not a pinned metadata-only message shell masking an active message.send.text adapter. (src/infra/outbound/channel-resolution.test.ts:166, 7799e5364216)

Likely related people:

vincentkoc: Git blame and log show commit db24e8e added the current src/infra/outbound/channel-resolution.ts and channel-bootstrap.runtime.ts code this PR modifies. (role: introduced current outbound resolver/bootstrap surface on main; confidence: medium; commits: db24e8e76b49; files: src/infra/outbound/channel-resolution.ts, src/infra/outbound/channel-bootstrap.runtime.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

TurboTheTurtle · 2026-06-04T06:31:57Z

Pushed a CI-unblocker for the plugin SDK testing barrel contract failure (checks-fast-contracts-plugins-a) plus retained the outbound fix.

Validation after the new commit:

node scripts/run-vitest.mjs src/plugins/contracts/plugin-sdk-package-contract-guardrails.test.ts --reporter=dot — 22 passed
node scripts/run-vitest.mjs src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts src/plugins/runtime.channel-pin.test.ts --reporter=dot — 35 passed
pnpm exec oxfmt --check --threads=1 packages/plugin-sdk/src/testing.ts src/infra/outbound/channel-resolution.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts — passed
pnpm exec oxlint packages/plugin-sdk/src/testing.ts src/infra/outbound/channel-resolution.ts src/infra/outbound/channel-bootstrap.runtime.ts src/infra/outbound/channel-resolution.test.ts src/infra/outbound/channel-bootstrap.runtime.test.ts — passed
git diff --check — passed

@clawsweeper re-review

clawsweeper · 2026-06-04T06:32:00Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26988215883
Updated: 2026-06-05T00:47:39.027Z

TurboTheTurtle · 2026-06-05T00:31:33Z

Added the redacted live Discord proof ClawSweeper requested to the PR body. Summary: PR-head gateway on OpenClaw 2026.6.2 (f62c3e0, full SHA f62c3e0912ee0a7aebe5db4910f7ec2ecd57781b) received a real Discord inbound message, completed the agent turn, delivered 1 final reply to the Discord channel, Discord API readback saw the expected reply, and the PR-head log had no Outbound not configured for channel: discord error. Temp PR-head gateway was stopped afterward and production gateway health was OK.

@clawsweeper re-review

clawsweeper · 2026-06-05T00:31:36Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27030990244
Updated: 2026-06-05T17:59:35.253Z

thewilloftheshadow · 2026-06-05T17:22:10Z

@clawsweeper automerge

clawsweeper · 2026-06-05T17:22:13Z

🦞🔧
ClawSweeper picked up the repair feedback.

Source: clawsweeper[bot]
Feedback: structured ClawSweeper marker: fix-required (finding=review-feedback sha=7799e53642164056dced9dfb2fa860df3b820966)
Action: repair worker queued. Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327
Model: gpt-5.5

I will update this PR branch, or open a safe credited replacement, if the repair worker finds a narrow fix.

Automerge progress:

2026-06-05 17:56:58 UTC Codex edit 1 4cbba1fd7f38 (complete) in 4m 43s Run: https://github.com/openclaw/clawsweeper/actions/runs/27030987163 exit 0

2026-06-05 18:00:42 UTC validation and review 1 7799e5364216 (complete) in 8m 26s Run: https://github.com/openclaw/clawsweeper/actions/runs/27030987163 already-current

2026-06-05 18:00:47 UTC repair completed 7799e5364216 (branch updated) in 8m 32s Run: https://github.com/openclaw/clawsweeper/actions/runs/27030987163 initial automerge rebase is delegated to Codex repair

2026-06-05 18:00:47 UTC review queued 7799e5364216 (after repair)

2026-06-05 18:10:50 UTC automerge wait 7799e5364216 (waiting) in 18m 34s Run: https://github.com/openclaw/clawsweeper/actions/runs/27030987163 waiting for exact-head ClawSweeper review pass

2026-06-05 18:10:51 UTC repair finished 7799e5364216 (pushed) in 18m 35s Run: https://github.com/openclaw/clawsweeper/actions/runs/27030987163 repair_contributor_branch

2026-06-07 07:53:16 UTC review queued 7799e5364216 (queued)

2026-06-07 08:17:51 UTC review requested repair 7799e5364216 (structured ClawSweeper marker: fix-required (finding=review-feedback sha=7799e5...)

2026-06-07 08:01:04 UTC repair queued 7799e5364216 (autonomous) Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327

2026-06-07 08:08:27 UTC repair started (running) in 1s Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327 automerge-openclaw-openclaw-90198

2026-06-07 08:09:36 UTC review queued 7799e5364216 (queued)

2026-06-07 08:09:59 UTC validation plan (passed) in 1m 33s Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327 pnpm check:changed; pnpm lint; pnpm check:test-types

2026-06-07 08:10:11 UTC Codex write preflight (passed) in 1m 45s Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327 danger-full-access

2026-06-07 08:16:53 UTC Codex edit 1 9d0fb6ad719a (complete) in 8m 27s Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327 exit 0

2026-06-07 08:20:21 UTC validation and review 1 d5fe7414c6d5 (base moved) in 11m 55s Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327 rebased

2026-06-07 08:20:46 UTC repair finished d5fe7414c6d5 (opened) in 12m 20s Run: https://github.com/openclaw/clawsweeper/actions/runs/27086801327 open_fix_pr

clawsweeper · 2026-06-05T18:12:55Z

🦞✅
ClawSweeper is pausing this repair loop for human review.

Source: clawsweeper[bot]
Reason: - [P1] Review did not complete, so no work-lane recommendation was made. (sha=7799e53642164056dced9dfb2fa860df3b820966)

Why human review is needed:
ClawSweeper found a blocker that should be resolved or accepted by a maintainer before the repair or automerge loop continues.

What the maintainer can do as a next step:
If the maintainer accepts the current risk and wants ClawSweeper to continue merge gates, comment @clawsweeper approve. If more work is needed, resolve the blocker first, then comment @clawsweeper automerge to re-review and continue. If automation should stay paused, leave clawsweeper:human-review in place or comment @clawsweeper stop.

I added clawsweeper:human-review and left the final call with a maintainer.

TurboTheTurtle · 2026-06-07T07:11:00Z

@thewilloftheshadow quick nudge on this one: ClawSweeper’s automerge loop paused on clawsweeper:human-review after the exact-head review failed to complete for 7799e5364216. CI and real behavior proof are passing from what I can see. If you’re comfortable with the current risk, could you comment @clawsweeper approve to continue the merge gates?

TurboTheTurtle · 2026-06-07T07:41:10Z

@clawsweeper re-review

clawsweeper · 2026-06-07T07:41:13Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27086414996
Updated: 2026-06-07T07:53:19.829Z

clawsweeper · 2026-06-07T08:20:44Z

ClawSweeper 🐠 reef update

Thanks for the contribution. ClawSweeper hit a branch-permission wall on this PR, so it opened a replacement branch to keep review moving while preserving credit.

Why replacement: ClawSweeper could not update the source PR branch directly; GitHub did not grant sufficient push rights to the bot for that branch.
Replacement PR: #91119
Why close: this run explicitly closes the superseded source PR after the credited replacement PR is open, so review continues in one place.
This source PR is being closed only under the explicit source-close setting for this ClawSweeper run.
The replacement PR carries the original credit trail forward.
Co-author credit kept:

@TurboTheTurtle: Co-authored-by: Andy Ye 35905412+TurboTheTurtle@users.noreply.github.com

fish notes: model gpt-5.5, reasoning high; reviewed against d5fe741.

openclaw-barnacle Bot added the size: M label Jun 4, 2026

openclaw-barnacle Bot added the proof: supplied External PR includes structured after-fix real behavior proof. label Jun 4, 2026

TurboTheTurtle force-pushed the fix/90162-discord-outbound-adapter branch from d3aefa9 to 65bfcde Compare June 4, 2026 06:26

clawsweeper Bot added the clawsweeper:automerge Maintainer opted this PR into bounded ClawSweeper-reviewed automerge label Jun 5, 2026

TurboTheTurtle and others added 2 commits June 5, 2026 17:27

fix(outbound): keep channel runtime adapters resolvable

77ddd81

fix(outbound): keep Discord runtime adapters resolvable

4cbba1f

clawsweeper Bot force-pushed the fix/90162-discord-outbound-adapter branch from f62c3e0 to 4cbba1f Compare June 5, 2026 17:35

clawsweeper Bot added the status: 🚀 automerge armed This PR is in ClawSweeper's automerge lane. label Jun 5, 2026

fix(outbound): keep Discord runtime adapters resolvable

7799e53

clawsweeper Bot mentioned this pull request Jun 7, 2026

fix(outbound): keep Discord runtime adapters resolvable #91119

Merged

clawsweeper Bot closed this Jun 7, 2026

TurboTheTurtle deleted the fix/90162-discord-outbound-adapter branch June 7, 2026 08:22

Uh oh!

Conversation

TurboTheTurtle commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Linked context

Real behavior proof (required for external PRs)

Tests and validation

Risk checklist

Current review state

Uh oh!

TurboTheTurtle commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurboTheTurtle commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurboTheTurtle commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurboTheTurtle commented Jun 5, 2026

Uh oh!

clawsweeper Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thewilloftheshadow commented Jun 5, 2026

Uh oh!

clawsweeper Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented Jun 5, 2026

Uh oh!

TurboTheTurtle commented Jun 7, 2026

Uh oh!

TurboTheTurtle commented Jun 7, 2026

Uh oh!

clawsweeper Bot commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented Jun 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

TurboTheTurtle commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 5, 2026 •

edited

Loading

clawsweeper Bot commented Jun 5, 2026 •

edited

Loading

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading