fix(cron): allow recovered early tool errors to succeed delivery (#94846) by ruomuxydt · Pull Request #94862 · openclaw/openclaw

ruomuxydt · 2026-06-19T07:45:33Z

Summary

An isolated scheduled agentTurn that recovers from an early missing-file tool error, produces final assistant output, and ends successfully was having delivery skipped. The cron finalization treated the earlier tool error as fatal because runLevelError (populated from finalRunResult.meta?.error) short-circuited all recovery detection in resolveCronPayloadOutcome.

Root cause

In src/cron/isolated-agent/helpers.ts, hasSuccessfulPayloadAfterLastError and hasSuccessfulPayloadBeforeLastError were gated behind !params.runLevelError. When the embedded runner propagated the early tool error as meta.error (a run-level error), the recovery signals from later successful payloads or finalAssistantVisibleText were ignored.

Additionally, hasFatalErrorPayload included || runLevelError !== undefined, so even when payload-level recovery was detected, the mere presence of runLevelError forced the run to status: error and skipped dispatchCronDelivery.

Fix

Two changes in src/cron/isolated-agent/helpers.ts:

Remove the !params.runLevelError gate from hasSuccessfulPayloadAfterLastError and hasSuccessfulPayloadBeforeLastError. Payload-level recovery signals (successful payloads after the last error) are now always respected regardless of whether runLevelError is set.
Change hasFatalErrorPayload from ... || runLevelError !== undefined to ... || (runLevelError !== undefined && !hasRecoveringTerminalOutput). A runLevelError alone does not force fatal when the trajectory proves recovery (later successful payloads or final assistant visible text).

The net effect: an early tool error that the agent recovers from no longer blocks delivery, while genuine fatal runs (no recovery evidence) remain correctly classified as status: error.

Real behavior proof

Behavior addressed: Isolated cron agentTurn jobs that recover from an early tool error (e.g. missing file) and produce final assistant output were having delivery skipped because runLevelError short-circuited recovery detection.

Real environment tested: Windows 10, Node 22.22.3, OpenClaw source checkout at 014d5f61, real Node process driving the real exported resolveCronPayloadOutcome function.

Exact steps or command run after this patch:

node --import tsx proof-cron-recovered-tool-error.mts recovered
node --import tsx proof-cron-recovered-tool-error.mts genuine-fatal

Evidence after fix (head 014d5f61):

=== recovered scenario (early error + later success + runLevelError) ===
[proof recovered] hasFatalErrorPayload=false
[proof PASS] recovered run correctly marked non-fatal

=== genuine-fatal (no recovery, still fatal) ===
[proof genuine-fatal] hasFatalErrorPayload=true
[proof PASS] genuine fatal correctly marked fatal

Observed result after fix: Before the patch, the recovered scenario returned hasFatalErrorPayload=true (the run was incorrectly treated as fatal, skipping delivery). After the patch, it returns hasFatalErrorPayload=false (delivery proceeds). The genuine-fatal control correctly remains hasFatalErrorPayload=true.

Unit tests (src/cron/isolated-agent/helpers.test.ts, 28/28 including 3 new tests covering both scenarios) validate the before/after behavior. Existing run.meta-error-status.test.ts (5/5) confirms no regression in genuine run-level error handling.

What was not tested: Not run against a live scheduled cron job with a real provider/channel; the proof drives the real resolveCronPayloadOutcome function in a real Node process with synthetic payloads that match the issue's trajectory shape.

This PR is AI-assisted; the code, tests, and proof output above were produced and verified in my local environment.

Co-Authored-By: Claude [email protected]

…nclaw#94846) When an isolated agentTurn recovers from an early tool error (e.g. missing file) and produces successful later payloads or final assistant output, the cron finalization was incorrectly treating the run as fatal because runLevelError short-circuited the recovery detection. Remove the runLevelError gate from hasSuccessfulPayloadAfterLastError/hasSuccessfulPayloadBeforeLastError so payload-level recovery signals are always respected. Also ensure hasFatalErrorPayload does not trigger on runLevelError alone when the trajectory proves recovery. Co-Authored-By: Claude <[email protected]>

clawsweeper · 2026-06-19T07:46:34Z

Codex review: needs real behavior proof before merge. Reviewed June 21, 2026, 11:15 PM ET / 03:15 UTC.

Summary
The PR changes isolated cron payload outcome handling and helper tests so recovered ⚠️ 🛠️ tool-warning runs with final output can be treated as non-fatal and delivered even when runLevelError is present.

PR surface: Source +13, Tests +97. Total +110 across 2 files.

Reproducibility: yes. at source level: current main still lets the linked recovered tool-warning trajectory be classified fatal before dispatch. I did not run a live scheduled cron job in this read-only review.

Review metrics: 1 noteworthy metric.

Run-level recovery predicates: 2 widened. Both successful-payload recovery checks now ignore runLevelError, which changes cron status and dispatch behavior beyond the reported tool-warning path.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #94846
Summary: This PR is one candidate fix for the canonical recovered isolated-cron tool-warning classification and pre-dispatch delivery-skip issue.

Members:

canonical: [Bug]: Cron isolated agentTurn skips delivery before dispatch when a recovered early tool error is classified as fatal #94846 - The PR uses closing syntax for this open issue and targets its recovered early tool-error delivery skip.
partial_overlap: fix(cron): detect recovered tool warnings without preferFinalAssistantVisibleText #94849 - This open PR also targets recovered tool warnings without channel output preference, but not the same run-level error semantics.
partial_overlap: fix(cron): treat cron tool warnings as non-fatal when run recovered #94855 - This open PR targets the same canonical issue through a different nonfatal tool-warning predicate.
partial_overlap: fix(cron): respect recovered tool errors #84156 - This open older PR targets recovered cron tool errors with broader all-error-payload semantics.
duplicate: Bug: isolated agentTurn cron marked error when exec exits 1, even when agent recovers and produces correct output #94863 - This closed issue reported the same recovered isolated cron tool-warning classification failure for another script/channel shape.
1 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦪 silver shellfish
Patch quality: 🧂 unranked krab
Result: blocked until stronger real behavior proof is added.

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

Rank-up moves:

[P1] Restrict run-level recovery so only known tool-warning recovery clears structured fatal suppression, or add an equivalent finalization guard.
[P1] Add a finalization-level regression proving generic fatal run-level errors do not call dispatchCronDelivery while recovered tool warnings do.
Update the PR body with redacted current-head terminal or log proof through cron finalization or delivery dispatch.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The PR body and follow-up comments provide helper-level terminal/unit proof, but not current-head proof through cron finalization or delivery dispatch for the changed user-visible behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

[P1] Generic run-level failures followed by success-looking payloads can remain status: error while still reaching normal cron delivery with fatal error text.
[P1] The latest proof is helper-level terminal/unit output, not current-head proof through cron finalization or delivery dispatch.
[P1] Several open PRs target the same recovered cron bug with different semantics, so maintainers need one canonical landing path.

Maintainer options:

Preserve fatal suppression while recovering tool warnings (recommended)
Keep the recovery escape limited to known cron tool-warning recovery and add a finalization regression that generic fatal run-level errors do not call normal delivery.
Choose one canonical cron branch
Pause this branch if maintainers prefer one of the overlapping candidate PRs after that branch proves the same finalization boundary.
Accept broader fatal delivery deliberately
Maintainers could intentionally accept broader fatal-error delivery only with explicit rationale for status, diagnostics, and sensitive error-text exposure.

Next step before merge

[P1] The code blocker is narrow, but the PR also needs contributor-supplied current-head finalization/delivery proof and maintainer consolidation with sibling cron PRs before merge.

Security
Needs attention: The patch can bypass the existing suppression that keeps fatal provider/tool error payloads out of normal cron completion delivery.

Review findings

[P1] Keep generic run-level errors out of delivery — src/cron/isolated-agent/helpers.ts:259-264

Review details

Best possible solution:

Land one canonical cron outcome fix that recovers known tool-warning trajectories while preserving true fatal structured-error suppression and proving the finalization dispatch boundary.

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

Yes, at source level: current main still lets the linked recovered tool-warning trajectory be classified fatal before dispatch. I did not run a live scheduled cron job in this read-only review.

Is this the best way to solve the issue?

No. The helper is the right layer, but this branch still needs a narrower fatality predicate or a finalization guard so generic run-level failures do not fall through to normal delivery.

Full review comments:

[P1] Keep generic run-level errors out of delivery — src/cron/isolated-agent/helpers.ts:259-264
Removing the runLevelError gate from these recovery checks lets a generic fatal run-level error followed by any success-looking payload clear hasFatalStructuredErrorPayload. run.ts only suppresses normal delivery for structured fatality, so the run can still call dispatchCronDelivery with fatal error text; keep this recovery limited to known cron tool-warning shapes or add a finalization guard.
Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against a1828110704f.

Label changes

Label justifications:

P2: This is a bounded cron delivery/status bug fix with real scheduled-workflow impact but limited blast radius.
merge-risk: 🚨 session-state: The diff changes fatal-versus-ok cron outcome classification and persisted diagnostics for isolated agent turns.
merge-risk: 🚨 message-delivery: The diff changes whether recovered and fatal isolated cron outputs reach direct completion delivery and which text is sent.
merge-risk: 🚨 security-boundary: The diff can bypass the branch that keeps fatal provider/tool error payloads out of normal delivery, where internal error text may be exposed.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body and follow-up comments provide helper-level terminal/unit proof, but not current-head proof through cron finalization or delivery dispatch for the changed user-visible behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +13, Tests +97. Total +110 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	26	13	+13
Tests	1	97	0	+97
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	123	13	+110

Security concerns:

[medium] Fatal error payloads can reach normal delivery — src/cron/isolated-agent/helpers.ts:259
By clearing hasFatalStructuredErrorPayload for generic run-level errors with later success-looking payloads, the PR can send fatal error text through the normal direct-delivery path that current code intentionally avoids for provider error JSON.
Confidence: 0.84

What I checked:

Root policy read and applied: Root AGENTS.md was read fully; its PR-review policy requires source, tests, related items, current behavior, history, and proof for cron/session delivery changes. (AGENTS.md:1, a1828110704f)
Current main still has the reported classifier gate: Current main keeps successful-payload recovery behind !params.runLevelError and recovered tool-warning recovery behind channel final-text preference, matching the source-level failure path from the linked issue. (src/cron/isolated-agent/helpers.ts:259, a1828110704f)
Finalization suppression depends on structured fatality: Current finalization skips normal dispatchCronDelivery only when hasFatalStructuredErrorPayload is true, so clearing that flag changes whether fatal text can enter normal delivery. (src/cron/isolated-agent/run.ts:1238, a1828110704f)
PR head still clears structured fatality too broadly: At PR head, the successful-payload recovery checks no longer require !runLevelError; a generic run-level failure followed by any successful payload can clear hasFatalStructuredErrorPayload while hasFatalErrorPayload remains true. (src/cron/isolated-agent/helpers.ts:259, c3fd0af91064)
Existing safety invariant: The adjacent runner test asserts fatal error payloads do not call normal announce delivery, which is the invariant this PR still needs to preserve for generic run-level failures. (src/cron/isolated-agent/run.message-tool-policy.test.ts:1114, a1828110704f)
Canonical issue remains open: The linked issue is still open and describes the same recovered isolated-cron pre-dispatch delivery skip that this PR attempts to fix.

Likely related people:

sercada: Authored the merged PR that added the fatal structured error suppression behavior this PR must preserve. (role: introduced adjacent fatal-delivery suppression; confidence: high; commits: 0c7220f5da78, 2e6ca9f703da; files: src/cron/isolated-agent/run.ts, src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent/run.message-tool-policy.test.ts)
steipete: Authored the current final-output-over-tool-warning helper work and merged the fatal announce suppression PR. (role: recent area contributor and merger; confidence: high; commits: c8a953af9371, 0c7220f5da78; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent/run.ts, src/cron/isolated-agent.helpers.test.ts)
welfo-beo: Authored the cron final announce delivery work that introduced finalAssistantVisibleText into this outcome path. (role: adjacent feature contributor; confidence: medium; commits: 81c7304a18b8; files: src/cron/isolated-agent/helpers.ts, src/cron/isolated-agent/run.ts, src/cron/isolated-agent.helpers.test.ts)
fsdwen: Authored recent channel output policy work that feeds the same recovered cron tool-warning decision surface. (role: adjacent output-policy contributor; confidence: medium; commits: b90f7d2fd004; files: src/cron/isolated-agent/channel-output-policy.ts, src/cron/isolated-agent/channel-output-policy.test.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.

…penclaw#94846) ClawSweeper review: the previous broadening let all runLevelError values be overridden by recovery signals. Narrow to non-terminal tool-warning evidence only: when the last error payload is a tool warning and the trajectory proves recovery, runLevelError is not fatal; generic run-level errors remain fatal regardless of recovery. Co-Authored-By: Claude <[email protected]>

ruomuxydt · 2026-06-19T08:02:42Z

Addressed review findings: narrowed the run-level recovery predicate to non-terminal tool-warning evidence only. When the last error payload is a tool warning (⚠️ 🛠️ prefix) and the trajectory proves recovery (later successful payloads or final assistant text), runLevelError is not fatal. Generic run-level errors (e.g. connection refused) remain fatal regardless of recovery signals.

Verified: 29/29 unit tests pass (including new test for generic run-level error remaining fatal). Real behavior proof passes on both recovered and genuine-fatal scenarios.

@clawsweeper re-review

clawsweeper · 2026-06-19T08:02:44Z

🦞🧹
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.

…penclaw#94846) When a recovered tool-warning run is accepted (hasFatalErrorPayload=false), the output fields (summary, outputText, deliveryPayloads) now reflect the successful payload text, not the formatted run-level error. This addresses ClawSweeper rank-up move: 'Fix the resolver so accepted recovered tool-warning runs return final assistant or successful payload text instead of the formatted run-level error.' Also gates shouldUseRunLevelErrorPayload behind hasFatalErrorPayload so the run-level error string is never surfaced as output when the run is recovered. Co-Authored-By: Claude <[email protected]>

ruomuxydt · 2026-06-19T08:48:52Z

Addressed all three rank-up moves from the previous review:

Resolver output fix: When a recovered tool-warning run is accepted (hasFatalErrorPayload=false), the output fields now reflect the successful payload text, not the formatted run-level error. shouldUseRunLevelErrorPayload is now gated behind hasFatalErrorPayload.
Focused assertions: Added assertions for summary, outputText, and deliveryPayloads in the recovered scenario test.
After-fix proof (head 8b6b787):

Recovered tool-warning scenario (early sed error + later success + runLevelError present):

hasFatalErrorPayload: false
summary: "Patch applied successfully." (successful payload text, not run-level error)
outputText: "Patch applied successfully."
deliveryPayloads: [{text: "Patch applied successfully."}]

Genuine-fatal scenario (no recovery):

hasFatalErrorPayload: true (unchanged)
Output fields correctly use run-level error path

29/29 unit tests pass including focused output-field assertions.

@clawsweeper re-review

clawsweeper · 2026-06-19T08:48:55Z

🦞🧹
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.

…ext recovery (openclaw#94846) Address ClawSweeper rank-up moves: 1. Preserve original error payload text for generic fatal run-level errors with later success-looking payloads, instead of surfacing the formatted run-level error as summary/outputText. 2. Add recovery path for tool-warning runs with only finalAssistantVisibleText (no successful payloads): when hasRecoveringTerminalOutput && isLastErrorAToolWarning, hasFatalStructuredErrorPayload is now false, so delivery proceeds using the final assistant text. 3. Gate shouldUseRunLevelErrorPayload behind hasFatalErrorPayload so run-level error text is never surfaced when the run is recovered. Co-Authored-By: Claude <[email protected]>

ruomuxydt · 2026-06-19T09:43:10Z

Addressed all three rank-up moves from the previous review:

Preserve original error payload text: For generic fatal run-level errors with later success-looking payloads, the output fields (summary, outputText) now preserve the original error payload text (e.g. "Fatal: connection refused"), not the formatted run-level error ("cron isolated run failed: connection refused").
finalAssistantVisibleText-only recovery: Added recovery path for tool-warning runs with only finalAssistantVisibleText and no successful payloads. When hasRecoveringTerminalOutput && isLastErrorAToolWarning, hasFatalStructuredErrorPayload is now false, so delivery proceeds using the final assistant text.
Gate shouldUseRunLevelErrorPayload: Run-level error text is never surfaced as output when the run is recovered (hasFatalErrorPayload=false).

31/31 unit tests pass including focused output-field assertions for both scenarios.

@clawsweeper re-review

clawsweeper · 2026-06-19T09:43: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.

…law#94846) When a recovered tool-warning run has finalAssistantVisibleText, the output fields (summary, outputText, deliveryPayloads) now use the recovered answer, not the stale warning payload, even for channels that do not prefer final assistant visible text. This addresses ClawSweeper rank-up move: 'Fix the no-preference finalAssistantVisibleText-only recovery case so the delivered payload is the recovered answer.' Co-Authored-By: Claude <[email protected]>

ruomuxydt · 2026-06-19T13:49:26Z

Addressed the no-preference rank-up move:

When a recovered tool-warning run has finalAssistantVisibleText, the output fields (summary, outputText, deliveryPayloads) now use the recovered answer even for channels that do not prefer final assistant visible text. The fatality escape and final-assistant text selection now use the same predicate (hasRecoveringTerminalOutput && isLastErrorAToolWarning).

Added focused test: 'delivers the recovered answer for no-preference channels when finalAssistantVisibleText exists' -- verifies summary/outputText/deliveryPayloads all use the recovered answer.

32/32 unit tests pass.

@clawsweeper re-review

clawsweeper · 2026-06-19T13:49:30Z

🦞🧹
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.

vincentkoc · 2026-07-04T05:14:00Z

maintainer closeout: this candidate is not safe to land.

It removes the runLevelError guards from successful-payload recovery and then lets a display-prefix tool warning plus final text clear both structured and run-level fatality. That can turn a real run-level failure or unresolved mutating tool failure into normal delivery.

Current cron has no degraded outcome: status: error drives not-delivered state, alerts, retries, and backoff, while status: ok clears those signals. Recovery therefore needs typed producer evidence, not ⚠️ 🛠️ text or success-looking assistant prose.

The canonical issue remains open for a typed exec failure-phase/process-started contract or a deliberate degraded cron outcome design.

openclaw-barnacle Bot added size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 19, 2026

openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 19, 2026

clawsweeper Bot mentioned this pull request Jun 19, 2026

Bug: isolated agentTurn cron marked error when exec exits 1, even when agent recovers and produces correct output #94863

Closed

openclaw-barnacle Bot added size: S and removed size: XS labels Jun 19, 2026

clawsweeper Bot mentioned this pull request Jun 19, 2026

fix(cron): detect recovered tool warnings regardless of channel policy #94867

Closed

clawsweeper Bot mentioned this pull request Jun 19, 2026

fix(cron): treat cron tool warnings as non-fatal when run recovered #94855

Closed

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 19, 2026

clawsweeper Bot added status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. and removed status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. labels Jun 19, 2026

clawsweeper Bot mentioned this pull request Jun 19, 2026

fix(cron): deliver recovered agent output despite early tool errors #94909

Closed

clawsweeper Bot added merge-risk: 🚨 security-boundary 🚨 May affect sandboxing, authorization, credentials, or sensitive data. and removed merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels Jun 19, 2026

vincentkoc closed this Jul 4, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(cron): allow recovered early tool errors to succeed delivery (#94846)#94862

fix(cron): allow recovered early tool errors to succeed delivery (#94846)#94862
ruomuxydt wants to merge 5 commits into
openclaw:mainfrom
ruomuxydt:fix/cron-isolated-delivery-recovered-tool-error-fork

ruomuxydt commented Jun 19, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

Uh oh!

vincentkoc commented Jul 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Summary

Root cause

Fix

Real behavior proof

Uh oh!

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

Uh oh!

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

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

Uh oh!

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

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

Uh oh!

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

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

Uh oh!

Uh oh!

ruomuxydt commented Jun 19, 2026

Uh oh!

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

Uh oh!

Uh oh!

vincentkoc commented Jul 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ruomuxydt commented Jun 19, 2026 •

edited

Loading

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading