fix(tasks): recover terminal lost cron rows by liaoandi · Pull Request #86088 · openclaw/openclaw

liaoandi · 2026-05-24T15:24:50Z

Replaces closed #75036 with the same task-registry fix on a narrow branch.

This keeps only the terminal lost cron recovery change and focused regression coverage. The previous PR branch had accumulated unrelated generated/runtime changes, so this branch was rebuilt from current main.

Real behavior proof

Behavior or issue addressed: Terminal lost cron task rows that were marked lost by a backing-session-missing false positive are recovered from durable cron run logs, and stale terminal errors are cleared when recovery has no error. Errorless terminal lost rows and rows with unrelated lost errors are not recovered.
Real environment tested: Local OpenClaw source checkout on macOS, branch fix/tasks-recover-terminal-lost-cron-narrow, head 445af4a, Node /opt/homebrew/opt/node/bin/node. The CLI proof used an isolated OPENCLAW_HOME and OPENCLAW_STATE_DIR under /private/tmp, with bundled plugins disabled. Commands were run from the current PR head through the source CLI entrypoint: node --import tsx src/entry.ts.
Exact steps or command run after this patch:

Seeded an isolated state directory with one durable task-registry sqlite row:
- runtime: "cron"
- status: "lost"
- error: "backing session missing"
- runId: "cron:proof-terminal-lost-cron:1764072000000"
Seeded the matching durable cron run log entry:
- action: "finished"
- status: "ok"
- summary: "done"
- runAtMs: 1764072000000
- durationMs: 1250
Ran current-head CLI list/preview/apply/list against the isolated state:
- node --import tsx src/entry.ts tasks list --json
- node --import tsx src/entry.ts tasks maintenance --json
- node --import tsx src/entry.ts tasks maintenance --apply --json
- node --import tsx src/entry.ts tasks list --json

Evidence after fix:

Seed output, with the temp path redacted:

{
  "stateDir": "<isolated-state>",
  "taskId": "task-proof-terminal-lost-cron",
  "jobId": "proof-terminal-lost-cron",
  "runId": "cron:proof-terminal-lost-cron:1764072000000",
  "seededStatus": "lost",
  "seededError": "backing session missing",
  "cronRunLog": "<isolated-state>/cron/runs/proof-terminal-lost-cron.jsonl"
}

Before maintenance, tasks list --json showed the durable row was terminal lost and still had the backing-session error:

{
  "count": 1,
  "tasks": [
    {
      "taskId": "task-proof-terminal-lost-cron",
      "runtime": "cron",
      "sourceId": "proof-terminal-lost-cron",
      "runId": "cron:proof-terminal-lost-cron:1764072000000",
      "status": "lost",
      "endedAt": 1764072060000,
      "lastEventAt": 1764072060000,
      "error": "backing session missing",
      "terminalSummary": "stale lost summary"
    }
  ]
}

Preview mode projected exactly one recovered task without mutating by command intent:

{
  "mode": "preview",
  "maintenance": {
    "tasks": {
      "reconciled": 0,
      "recovered": 1,
      "cleanupStamped": 0,
      "pruned": 0
    }
  },
  "tasks": {
    "total": 1,
    "terminal": 1,
    "byStatus": {
      "succeeded": 1,
      "lost": 0
    },
    "byRuntime": {
      "cron": 1
    }
  }
}

Apply mode recovered the persisted task:

{
  "mode": "apply",
  "maintenance": {
    "tasks": {
      "reconciled": 0,
      "recovered": 1,
      "cleanupStamped": 0,
      "pruned": 0
    }
  },
  "tasks": {
    "total": 1,
    "terminal": 1,
    "byStatus": {
      "succeeded": 1,
      "lost": 0
    },
    "byRuntime": {
      "cron": 1
    }
  }
}

After --apply, tasks list --json showed the row persisted as succeeded, used the durable run-log finish time, set the durable summary, and cleared the stale error field:

{
  "count": 1,
  "tasks": [
    {
      "taskId": "task-proof-terminal-lost-cron",
      "runtime": "cron",
      "sourceId": "proof-terminal-lost-cron",
      "runId": "cron:proof-terminal-lost-cron:1764072000000",
      "status": "succeeded",
      "endedAt": 1764072001250,
      "lastEventAt": 1764072001250,
      "terminalSummary": "done"
    }
  ]
}

Focused regression output from the same branch still covers the important boundaries:

✓ |tasks| src/tasks/task-registry.test.ts > task-registry > clears terminal errors when explicitly updated without an error
✓ |tasks| src/tasks/task-registry.maintenance.issue-60299.test.ts > task-registry maintenance issue #60299 > recovers terminal lost cron tasks from durable run logs
✓ |tasks| src/tasks/task-registry.maintenance.issue-60299.test.ts > task-registry maintenance issue #60299 > does not recover terminal lost cron tasks without a backing-session error
✓ |tasks| src/tasks/task-registry.maintenance.issue-60299.test.ts > task-registry maintenance issue #60299 > does not recover terminal lost cron tasks with non-backing-session errors

Test Files  2 passed (2)
Tests  90 passed (90)

Observed result after fix: The current-head CLI proof recovered the isolated terminal lost cron task from durable cron logs, changed persisted status from lost to succeeded, rewrote endedAt/lastEventAt to the durable finish timestamp, set terminalSummary to done, and cleared the stale error field.
What was not tested: I did not run a live scheduled cron job through a full gateway process in this PR. The proof uses an isolated seeded registry plus durable cron run log and then runs the real current-head tasks maintenance CLI preview/apply/list flow against that state.

Review follow-up:

Tightened terminal lost cron recovery to require the backing session missing signal.
Added coverage proving errorless terminal lost cron rows are not recovered.
Removed the direct CHANGELOG.md edit per review; release-note context remains in this PR body for squash/release tooling.

clawsweeper · 2026-05-24T15:27:25Z

Codex review: needs maintainer review before merge. Reviewed June 29, 2026, 7:57 AM ET / 11:57 UTC.

Summary
The PR extends task-registry maintenance to recover terminal lost cron rows with backing-session-missing errors from durable cron state/logs and to clear stale terminal error fields, with focused regression coverage.

PR surface: Source +17, Tests +172. Total +189 across 4 files.

Reproducibility: yes. source-reproducible. Current main and v2026.6.10 only recover active cron tasks from durable cron history, while the PR body supplies after-fix CLI maintenance output for the terminal lost-row path.

Review metrics: 1 noteworthy metric.

Persisted terminal recovery path: 1 added. The diff adds a maintenance path that can rewrite already-terminal cron task rows, which is the key state-safety decision before merge.

Root-cause cluster
Relationship: canonical
Canonical: #86088
Summary: This PR is the current narrow landing candidate for terminal lost cron recovery; the predecessor is closed unmerged, related reports are closed or broader, and newer cron restart work is adjacent rather than a replacement.

Members:

superseded: fix(tasks): recover terminal lost cron rows #75036 - Closed unmerged predecessor with the same useful task-registry fix but a broad dirty branch; this PR rebuilds the change narrowly.
fixed_by_candidate: [Bug]: cron run history can say finished ok while task audit still reports lost backing session missing #63196 - Closed report describes cron run history finishing ok while task audit still reports lost backing-session-missing, which this PR's terminal-lost recovery candidate addresses.
partial_overlap: tasks maintenance --apply is a no-op for lost (backing-session-missing) and stale_running task records #72884 - The broad maintenance no-op report includes terminal lost cron rows but also stale-running and timestamp cleanup cases outside this PR.
partial_overlap: False-positive lost cron task records after gateway restart due to transient activeJobIds backing-session check #68191 - The issue covers false-positive lost cron records after restart; this PR handles already-terminal run-log recovery while startup-liveness work covers the pre-terminal race.
partial_overlap: [Bug]: task maintenance can keep stale cli/cron tasks running forever when childSessionKey is blank or persistent #60299 - The older stale-running report is the test-file lineage for task maintenance, but this PR targets terminal lost cron rows rather than the full stale-running problem.
3 more in the report.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

[P2] Get task/session-state owner acceptance for the terminal lost cron rewrite boundary before merge.

Risk before merge

[P1] Merging can rewrite already-terminal persisted cron task rows: a lost row with the backing-session-missing signal can become succeeded, failed, or timed_out, with timestamps, summary, and error refreshed from durable cron history.
[P1] The supplied real behavior proof uses an isolated seeded registry plus the real CLI maintenance path, not a full live scheduled cron job through a gateway process.
[P1] Adjacent cron restart work at cron: restart-interrupted run mislabeled lost instead of failed (recovery matches reservation timestamp vs run id started-at) #96161 and fix(cron): mark interrupted restart runs failed instead of lost #96174 is distinct rather than superseding, but maintainers may want the same task/session-state owner to review both boundaries together.

Maintainer options:

Accept Narrow Terminal Recovery (recommended)
Merge after a task/session-state owner accepts that only terminal lost cron rows with the backing-session-missing signal may be rewritten from durable cron history.
Require Live Gateway Cron Proof
Ask for a full scheduled-cron gateway proof if seeded CLI maintenance output is not enough evidence for this persisted-state rewrite.
Review With Adjacent Restart Work
Pause this PR until the adjacent restart recovery work is reviewed if maintainers want both cron task-state boundaries considered together.

Next step before merge

[P2] The remaining action is maintainer acceptance of the persisted terminal-row rewrite boundary, not a narrow automated code repair.

Security
Cleared: No concrete security or supply-chain concern was found; the diff changes task-registry reconciliation logic and tests only.

Review details

Best possible solution:

Land the narrowed recovery after task/session-state owner acceptance, or require live gateway cron proof first if seeded CLI proof is not enough.

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

Yes, source-reproducible. Current main and v2026.6.10 only recover active cron tasks from durable cron history, while the PR body supplies after-fix CLI maintenance output for the terminal lost-row path.

Is this the best way to solve the issue?

Yes, subject to owner acceptance. The patch reuses the existing durable cron recovery source of truth and narrows terminal-row recovery to the backing-session-missing false-positive path; pruning would discard durable completion truth.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: This is a focused task-registry correctness fix with limited blast radius, but it affects persisted task state and operator audit output.
merge-risk: 🚨 session-state: The diff can change persisted terminal cron task status, timestamps, summary, and error fields during maintenance.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes copied terminal JSON from a real source CLI maintenance preview/apply/list flow against an isolated seeded state directory, plus focused regression output.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied terminal JSON from a real source CLI maintenance preview/apply/list flow against an isolated seeded state directory, plus focused regression output.

Evidence reviewed

PR surface:

Source +17, Tests +172. Total +189 across 4 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	23	6	+17
Tests	2	173	1	+172
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	4	196	7	+189

What I checked:

Repository policy read and applied: Root AGENTS.md was read fully and its persisted-state/session-state review guidance affected the merge-risk assessment; there is no scoped src/tasks/AGENTS.md. (AGENTS.md:16, db2488b6e3d6)
Current main still requires active cron tasks for durable recovery: On current main, resolveDurableCronTaskRecovery() returns early unless the task is runtime: "cron" and active, so an already-terminal lost cron row is not recovered from durable cron history. (src/tasks/task-registry.maintenance.ts:457, db2488b6e3d6)
Latest release has the same active-only guard: The latest release tag v2026.6.10 keeps the active-task requirement in the durable cron recovery path, so this PR's behavior is not already shipped. (src/tasks/task-registry.maintenance.ts:456, aa69b12d0086)
PR head narrows terminal lost recovery to backing-session-missing rows: The PR adds isRecoverableLostCronTask() and permits inactive cron recovery only for lost rows whose error contains the backing-session-missing signal. (src/tasks/task-registry.maintenance.ts:360, 15a5b023cb75)
PR head clears stale terminal errors intentionally: The patch teaches updateTask() and markTaskTerminalById() to distinguish an omitted error from an explicit error: undefined, allowing recovery without a durable error to remove the stale lost error field. (src/tasks/task-registry.ts:1183, 15a5b023cb75)
Regression tests cover recovery and exclusion boundaries: The PR tests recovery of a terminal lost cron row with the backing-session-missing error, and non-recovery for errorless or unrelated lost errors. (src/tasks/task-registry.maintenance.issue-60299.test.ts:541, 15a5b023cb75)

Likely related people:

steipete: Authored earlier stale cron/chat-backed task reconciliation and durable cron recovery work in the same task-maintenance files. (role: recent stale-cron recovery contributor; confidence: high; commits: 7d1575b5df79, 1fae716a04e5, 606e3d78669a; files: src/tasks/task-registry.maintenance.ts, src/tasks/task-registry.maintenance.issue-60299.test.ts, docs/automation/tasks.md)
vincentkoc: Recent commit history shows repeated maintenance of task-registry and task-maintenance internals near the recovery path this PR changes. (role: recent task-registry area contributor; confidence: high; commits: 273eed4c51cb, 29e44f5ebad3, d9a38130b1a8; files: src/tasks/task-registry.maintenance.ts, src/tasks/task-registry.ts)
liuhao1024: Recently changed reconcileInspectableTasks() behavior in the same maintenance module, which is one of the user-facing paths affected by projected recovery. (role: recent adjacent contributor of inspection path; confidence: medium; commits: e567986355bc; files: src/tasks/task-registry.maintenance.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.

clawsweeper · 2026-05-24T15:36:24Z

ClawSweeper PR egg

✨ Hatched: 🥚 common Brave Review Wisp

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

Merged PRs are hatchable.
Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: sparkles near resolved comments.
Image traits: location artifact grotto; accessory rollback rope; palette violet, aqua, and starlight; mood determined; pose stepping out of a freshly hatched shell; shell matte ceramic shell; lighting gentle morning glow; background little resolved-comment flags.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Brave Review Wisp in ClawSweeper.

What is this egg doing here?

Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

martingarramon

Explicitly carrying the error key, then deleting it when recovery.error is undefined, distinguishes "clear this field" from "omit this field". The old conditional spread couldn't express that, so recovered tasks could retain stale lost-state error values.

CI: Real behavior proof gate is failing. Rename Verification: → ## Real behavior proof and paste verbose vitest output (each test name + result), not just the command, to clear it.

Question on isRecoverableLostCronTask: the !error branch returns true when task.error is absent or empty — not only when it contains "backing session missing". Since markTaskLostById takes error as optional, this branch isn't dead code. Given the durable-completion check, is it intentionally safe to recover errorless terminal lost cron tasks, or should this gate still require the "backing session missing" substring?

martingarramon

LGTM on the behavior fix. The previous !error || error.includes(...) path made every errorless lost task recoverable. Requiring the explicit backing session missing signal is a tighter recovery condition, and the new test covers the important boundary: a lost cron task without an error string is not recovered. Real behavior proof is still failing, so that proof section needs to pass before merge.

liaoandi · 2026-05-26T07:27:10Z

@clawsweeper re-review

clawsweeper · 2026-05-26T07:27: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/26438584550
Updated: 2026-05-26T07:33:42.198Z

clawsweeper · 2026-05-29T10:44:48Z

🦞🧹
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/26632823592
Updated: 2026-05-29T10:52:07.332Z

altaywtf · 2026-06-29T12:32:52Z

Merged via squash.

Prepared head SHA: 15a5b023cb75aaad8ba29da1d8f5ad81751832d1
Landed commit: be94853de0d0a282cfbe63316084a73613819084

* fix(tasks): recover terminal lost cron rows * fix(tasks): require backing-session lost recovery signal * fix(tasks): satisfy has-own lint rule --------- Co-authored-by: Altay <[email protected]> (cherry picked from commit be94853)

* fix(tasks): recover terminal lost cron rows * fix(tasks): require backing-session lost recovery signal * fix(tasks): satisfy has-own lint rule --------- Co-authored-by: Altay <[email protected]>

* fix(tasks): recover terminal lost cron rows * fix(tasks): require backing-session lost recovery signal * fix(tasks): satisfy has-own lint rule --------- Co-authored-by: Altay <[email protected]> (cherry picked from commit be94853)

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

openclaw-barnacle Bot removed the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 24, 2026

clawsweeper Bot added rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels May 24, 2026

martingarramon reviewed May 24, 2026

View reviewed changes

openclaw-barnacle Bot added size: M triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. and removed size: S proof: sufficient ClawSweeper judged the real behavior proof convincing. labels May 25, 2026

liaoandi force-pushed the fix/tasks-recover-terminal-lost-cron-narrow branch from 6b2b511 to 742e16f Compare May 25, 2026 11:25

martingarramon reviewed May 25, 2026

View reviewed changes

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 May 25, 2026

liaoandi force-pushed the fix/tasks-recover-terminal-lost-cron-narrow branch from 742e16f to 39e5e07 Compare May 25, 2026 16:33

clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. labels May 25, 2026

liaoandi force-pushed the fix/tasks-recover-terminal-lost-cron-narrow branch 2 times, most recently from d19d1e6 to 384e1fd Compare May 26, 2026 03:56

liaoandi force-pushed the fix/tasks-recover-terminal-lost-cron-narrow branch from 384e1fd to 445af4a Compare May 26, 2026 07:25

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

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 26, 2026

clawsweeper Bot mentioned this pull request May 28, 2026

fix(cron): guard task liveness during startup #80707

Closed

liaoandi force-pushed the fix/tasks-recover-terminal-lost-cron-narrow branch from 445af4a to c6b0355 Compare May 29, 2026 10:38

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

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 29, 2026

yetval mentioned this pull request Jun 23, 2026

cron: restart-interrupted run mislabeled lost instead of failed (recovery matches reservation timestamp vs run id started-at) #96161

Open

clawsweeper Bot mentioned this pull request Jun 24, 2026

fix(cron): mark interrupted restart runs failed instead of lost #96174

Open

liaoandi added 2 commits June 29, 2026 14:37

fix(tasks): recover terminal lost cron rows

0643b29

fix(tasks): require backing-session lost recovery signal

bfcad5e

altaywtf force-pushed the fix/tasks-recover-terminal-lost-cron-narrow branch from c6b0355 to bfcad5e Compare June 29, 2026 11:37

fix(tasks): satisfy has-own lint rule

15a5b02

altaywtf self-assigned this Jun 29, 2026

altaywtf merged commit be94853 into openclaw:main Jun 29, 2026
94 checks passed

github-actions Bot mentioned this pull request Jun 29, 2026

📡 Upstream Digest — 2026-06-29 13:58 UTC curtismercier/openclaw-mods#1173

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(tasks): recover terminal lost cron rows#86088

fix(tasks): recover terminal lost cron rows#86088
altaywtf merged 3 commits into
openclaw:mainfrom
liaoandi:fix/tasks-recover-terminal-lost-cron-narrow

liaoandi commented May 24, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 24, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 24, 2026 •

edited

Loading

Uh oh!

martingarramon left a comment

Uh oh!

martingarramon left a comment

Uh oh!

liaoandi commented May 26, 2026

Uh oh!

clawsweeper Bot commented May 26, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 29, 2026 •

edited

Loading

Uh oh!

Uh oh!

altaywtf commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

liaoandi commented May 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Real behavior proof

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Hatch command

Uh oh!

martingarramon left a comment

Choose a reason for hiding this comment

Uh oh!

martingarramon left a comment

Choose a reason for hiding this comment

Uh oh!

liaoandi commented May 26, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

altaywtf commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

liaoandi commented May 24, 2026 •

edited

Loading

clawsweeper Bot commented May 24, 2026 •

edited

Loading

clawsweeper Bot commented May 24, 2026 •

edited

Loading

clawsweeper Bot commented May 26, 2026 •

edited

Loading

clawsweeper Bot commented May 29, 2026 •

edited

Loading