Skip to content

fix(channels): recover stale ingress queue claims at gateway startup#90989

Open
849261680 wants to merge 6 commits into
openclaw:mainfrom
849261680:worktree-fix-90945-sqlite-stale-claims
Open

fix(channels): recover stale ingress queue claims at gateway startup#90989
849261680 wants to merge 6 commits into
openclaw:mainfrom
849261680:worktree-fix-90945-sqlite-stale-claims

Conversation

@849261680

@849261680 849261680 commented Jun 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

  • Problem: Issue channel_ingress_events (SQLite): stale claims never recovered after session crash — Telegram DM deadlocks #90945 — after a gateway crash, channel_ingress_events rows left in claimed state are never recovered. Every new message into the affected session adds another stuck claim, silently deadlocking the channel (observed with Telegram DM). Per-queue recovery (recoverStaleClaims) only runs inside channel drain loops, which have not started yet right after a crash, so the claimed rows sit unrecovered until manual intervention.

  • Fix: Add recoverAllStaleChannelIngressClaims() in ingress-queue.ts and run it from prepareGatewayPluginBootstrap (before startChannels()) via a new runStartupIngressClaimSweep, mirroring the existing runStartupSessionMigration pattern. The sweep selects all claimed rows, keeps those older than staleMs (default 60s) whose owner process is gone, and batch-releases them to pending in a single write transaction. It is best-effort and non-blocking — failures are caught, logged, and startup continues.

  • Claim-owner liveness: claim_owner is either a bare PID (queue default) or a compound ${pid}:${uuid} (Telegram spool — extensions/telegram/src/telegram-ingress-spool.ts). Liveness parses the PID prefix before : (matching the spool's own processPidFromOwnerId), so a live sibling gateway's compound claim is never misread as dead.

  • Race guard: Each release is guarded by the exact claim_token observed during selection. Between the read and the write a sibling gateway could release and re-claim the same event (new token); releasing on status = "claimed" alone would drop that fresh claim into duplicate processing. The sweep also returns the actual number of rows affected.

  • What changed:

    • src/channels/message/ingress-queue.ts — new exported recoverAllStaleChannelIngressClaims() (+ staleMs age guard, claim_token release guard) and isIngressClaimProcessAlive() (parses bare and compound PID owners).
    • src/gateway/server-startup-ingress-sweep.ts — new startup sweep, follows the server-startup-session-migration.ts pattern (deps injection, try/catch with warn).
    • src/gateway/server-startup-plugins.ts — wires the sweep into prepareGatewayPluginBootstrap alongside existing startup tasks (+5 lines).
    • src/channels/message/ingress-queue.test.ts — 8 new sweep tests (see Evidence).
    • src/gateway/server-startup-ingress-sweep.test.ts — 3 new tests: success logging, error recovery, no-op path.

  • What did NOT change (scope boundary): per-queue recoverStaleClaims(), claimNext(), and Telegram spool recovery are unchanged — the startup sweep is additive. No config, plugin, or gateway-protocol surface changes.

Reproduction

  1. Active Telegram DM session with messages flowing through channel_ingress_events.
  2. Kill the gateway mid-turn (kill -HUP <pid>).
  3. channel_ingress_events now contains rows with status = "claimed" and claim_owner = dead PID.
  4. Restart gateway — before this PR: claims stay stuck, channel deadlocked. After: claims older than 60s with dead owners are released to pending before channels start, messages resume.

Real behavior proof

Behavior addressed: After a gateway crash, stale claimed rows in channel_ingress_events are recovered at next startup; live local and sibling-gateway claims (bare PID, compound pid:uuid, and rows re-claimed by a live worker) are preserved; channel message processing resumes. Fixes #90945.

Real environment tested: macOS Darwin 24.6.0, Node 22.22. Two layers: (1) the SQLite claim lifecycle is exercised against real on-disk state databases (created via openOpenClawStateDatabase, no mocks) by deterministic Vitest cases covering dead, live-bare-PID, live-compound-PID, re-claimed-by-live-worker, null, and recent-but-dead owners; (2) a real openclaw gateway process booted against an isolated state DB pre-seeded with a stuck claim, simulating recovery after a crashed session.

Exact steps or command run after this patch:

# Seed a stuck claim (status=claimed, dead PID 999999999, claimed 2 min ago) into an
# isolated state DB, then boot the real gateway and watch startup recover it.
OPENCLAW_STATE_DIR=/tmp/oc-proof OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_PORT=8899 \
  node scripts/run-node.mjs --dev gateway

# Unit layer
pnpm test src/channels/message/ingress-queue.test.ts src/gateway/server-startup-ingress-sweep.test.ts

Evidence after fix: Live gateway startup recovery (real openclaw gateway process, isolated state DB) —

BEFORE boot: [{"queue_name":"[\"telegram\",\"dm\"]","event_id":"tg-msg-1",
              "status":"claimed","claim_owner":"999999999","claimed_at":1780779945399}]

2026-06-07T05:08:35 Dev config ready: /tmp/oc-proof/state/openclaw.json
2026-06-07T05:08:37 [gateway] recovered 1 stale channel ingress claim(s) from previous session
2026-06-07T05:08:38 [gateway] http server listening (9 plugins: ...)
2026-06-07T05:08:38 [gateway] ready

AFTER boot:  [{"queue_name":"[\"telegram\",\"dm\"]","event_id":"tg-msg-1",
              "status":"pending","claim_owner":null,
              "last_error":"recovered at startup: owner process gone"}]

Unit layer:

 ✓ src/gateway/server-startup-ingress-sweep.test.ts (3 tests)
 ✓ src/channels/message/ingress-queue.test.ts (16 tests)
   ✓ recoverAllStaleChannelIngressClaims > recovers claims with dead owner PIDs across multiple queues
   ✓ recoverAllStaleChannelIngressClaims > preserves claims owned by the current process
   ✓ recoverAllStaleChannelIngressClaims > preserves live compound claim owners (Telegram spool `pid:uuid`)
   ✓ recoverAllStaleChannelIngressClaims > does not release a stale event that was re-claimed by a live worker
   ✓ recoverAllStaleChannelIngressClaims > returns zero when there are no claimed rows
   ✓ recoverAllStaleChannelIngressClaims > recovers claims with null or empty claim_owner
   ✓ recoverAllStaleChannelIngressClaims > skips claims newer than staleMs even with dead PIDs
   ✓ recoverAllStaleChannelIngressClaims > preserves recent claims within staleMs window
 Test Files  2 passed (2)

Observed result after fix: On a real gateway boot, the stuck claimed row (dead PID, 2 min old) was released to pending before channels started — exactly the deadlock-clearing transition #90945 needs, so the event is deliverable again. Live owners (bare and compound pid:uuid) and rows re-claimed by a live worker are preserved; recent claims within the staleMs window are age-protected; the sweep is best-effort and does not block startup on failure.

What was not tested: An end-to-end Telegram transport round-trip (sending a real DM, crashing mid-turn, observing it resume in the Telegram client). The recovery mechanism — the gateway startup sweep transitioning the SQLite claim from claimed to pending — is proven above with a real gateway process; a Telegram round-trip would only add transport-layer coverage on top of the proven claim-lifecycle fix.

Risk / Mitigation

  • PID recycling: after a crash the OS could reuse a dead PID. The 60s staleMs window means only old claims are candidates, so a recycled PID from a recently-started process won't match. Same trade-off as the existing Telegram spool recovery.
  • Sibling gateway re-claim: a sibling could release + re-claim a row between this sweep's read and write. The claim_token guard releases only the exact claim that was inspected, so a fresh claim is never dropped (regression test: "does not release a stale event that was re-claimed by a live worker").
  • Large backlogs: all releases batch into a single write transaction.

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • channels
  • gateway

Linked Issue/PR

Fixes #90945

@openclaw-barnacle openclaw-barnacle Bot added gateway Gateway runtime size: M triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 6, 2026
@clawsweeper

clawsweeper Bot commented Jun 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 3:55 PM ET / 19:55 UTC.

Summary
The branch adds a gateway-startup sweep that requeues stale claimed channel_ingress_events rows and threads restart-skip state through gateway CLI/server startup paths with regression tests.

PR surface: Source +210, Tests +422. Total +632 across 12 files.

Reproducibility: yes. at source level. Current main has only queue-local recovery and no gateway-wide startup sweep, and the linked issue plus PR proof show stale claimed rows blocking Telegram ingress after crashes or restarts.

Review metrics: 3 noteworthy metrics.

  • Startup State Mutation: 1 sweep added. The PR adds boot-time mutation of persisted ingress queue rows, which is message-delivery sensitive before merge.
  • Restart Skip Gates: 3 skip paths added. SIGUSR1, spawned handoff, and supervised handoff skips decide when startup recovery may touch queued message state.
  • Transient Restart Marker: 1 marker added. The PR adds a restart-only skip marker that must be reconciled with current main's SQLite restart-handoff path.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #90945
Summary: This PR is the open implementation candidate for the canonical SQLite channel_ingress_events stale-claim recovery issue; newer Telegram live-owned/spool fixes overlap but do not replace the gateway startup sweep.

Members:

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

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

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

Rank-up moves:

  • Resolve the current conflicts against main's SQLite restart-handoff implementation.
  • Rerun the focused queue, gateway startup, restart, oxlint, and git diff --check validation on the refreshed head.
  • Optionally capture Telegram Desktop proof showing a stale DM ingress claim recovery resumes visible replies.

Mantis proof suggestion
A native Telegram recording would add transport-level confidence beyond the SQLite startup logs. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis telegram desktop proof: verify a stale Telegram DM ingress claim is recovered after gateway restart and later messages get replies.

Risk before merge

  • [P1] GitHub reports the PR as conflicting/dirty, and current main moved restart handoffs to SQLite, so the restart skip wiring needs a current-base refresh before validation can be trusted.
  • [P1] The startup sweep requeues persisted channel_ingress_events claims based on age; if the restart boundary is wrong, inbound messages could be duplicated or delayed.
  • [P1] The supplied proof shows the real SQLite recovery transition through gateway startup logs, but it does not show a full live Telegram DM crash-and-resume round trip.

Maintainer options:

  1. Resolve Conflicts Against SQLite Handoff (recommended)
    Refresh the branch onto current main, port the skip guard to the current SQLite restart-handoff implementation, and rerun focused queue, startup, restart, lint, and diff checks.
  2. Accept Age-Based Startup Recovery
    Maintainers can accept the persisted-state mutation risk if they agree that an age threshold is the right boundary for crash-left ingress claims.
  3. Pause For Lease Design
    Pause or close this branch if maintainers want durable claim-owner leases or heartbeats instead of startup age-based recovery.

Next step before merge

  • [P2] The branch is the existing candidate fix, but the remaining action is maintainer conflict resolution and upgrade-safety review rather than a separate automated repair lane.

Security
Cleared: The diff changes local SQLite recovery, gateway startup/restart wiring, and tests; it adds no dependency, workflow, secret, permission, package, or remote execution surface.

Review details

Best possible solution:

Rebase onto current main, adapt the skip guards to the SQLite restart-handoff path, preserve the token-guarded startup sweep, and merge only after focused queue/startup/restart validation confirms no live inbound work is requeued.

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

Yes, at source level. Current main has only queue-local recovery and no gateway-wide startup sweep, and the linked issue plus PR proof show stale claimed rows blocking Telegram ingress after crashes or restarts.

Is this the best way to solve the issue?

Yes for the direction, but not ready as-is. Startup recovery is the right layer for crash-left SQLite ingress claims before channel drains start, while the current branch must be adapted to main's SQLite restart-handoff path and revalidated.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

  • add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
  • remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.

Label justifications:

  • P1: The PR targets a real broken inbound channel workflow where Telegram messages can remain undelivered after gateway crashes or restarts.
  • merge-risk: 🚨 message-delivery: The diff requeues persisted channel ingress claims at startup, so an incorrect recovery boundary could duplicate or disrupt inbound delivery.
  • rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The PR body and comments include after-fix real gateway startup logs showing a seeded stale SQLite claim move from claimed to pending; live Telegram proof would be stronger but is not required for the DB transition shown.
  • proof: sufficient: Contributor real behavior proof is sufficient. The PR body and comments include after-fix real gateway startup logs showing a seeded stale SQLite claim move from claimed to pending; live Telegram proof would be stronger but is not required for the DB transition shown.
  • mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The user-visible effect is Telegram inbound delivery getting unstuck after stale claim recovery, which can be demonstrated in a short Telegram Desktop proof.
Evidence reviewed

PR surface:

Source +210, Tests +422. Total +632 across 12 files.

View PR surface stats
Area Files Added Removed Net
Source 8 215 5 +210
Tests 4 426 4 +422
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 12 641 9 +632

Acceptance criteria:

  • [P1] node scripts/run-vitest.mjs src/channels/message/ingress-queue.test.ts src/gateway/server-startup-ingress-sweep.test.ts src/cli/gateway-cli/run-loop.test.ts src/cli/gateway-cli/run.option-collisions.test.ts.
  • [P1] node scripts/run-oxlint.mjs src/channels/message/ingress-queue.ts src/channels/message/ingress-queue.test.ts src/gateway/server-startup-ingress-sweep.ts src/gateway/server-startup-ingress-sweep.test.ts src/cli/gateway-cli/run-loop.ts src/infra/restart-handoff.ts.
  • [P1] git diff --check.

What I checked:

  • Repository policy read and applied: Root policy plus scoped channel/gateway guidance were read; persisted channel state, gateway startup, and Telegram proof rules affected the review. (AGENTS.md:1, 076da567f434)
  • Scoped channel policy read: The channel guide marks src/channels/** as shared core channel implementation and warns that shared channel changes affect routing and delivery across channels. (src/channels/AGENTS.md:1, 076da567f434)
  • Scoped gateway policy read: The gateway guide applies because the patch changes startup bootstrap behavior before plugins and channels start. (src/gateway/AGENTS.md:1, 076da567f434)
  • Current main lacks a startup ingress sweep: Current main runs channel startup maintenance and startup session migration, but no all-queue stale channel_ingress_events sweep in prepareGatewayPluginBootstrap. (src/gateway/server-startup-plugins.ts:63, 076da567f434)
  • Current queue recovery is queue-local: Current main has recoverStaleClaims() and optional claimNext({ staleMs }), but that recovery is scoped to one constructed queue and is not invoked globally at gateway startup. (src/channels/message/ingress-queue.ts:459, 076da567f434)
  • PR adds global stale-claim recovery: The PR head adds recoverAllStaleChannelIngressClaims(), selecting all claimed rows older than staleMs and requeueing them with a claim-token guard. (src/channels/message/ingress-queue.ts:861, e30ce44cbead)

Likely related people:

  • steipete: GitHub history maps the SQLite channel ingress queue introduction to refactor(channels): store inbound queues in SQLite, the central storage path for this PR. (role: introduced shared queue storage; confidence: high; commits: b0679d1f13da; files: src/channels/message/ingress-queue.ts, src/state/openclaw-state-schema.sql, extensions/telegram/src/telegram-ingress-spool.ts)
  • vincentkoc: Recent history touches both the shared ingress queue/Telegram claim recovery path and the current main restart-handoff SQLite conversion that this PR now conflicts with. (role: recent area contributor; confidence: high; commits: b8e3de11608d, a39a3b74de05, b4cdd9211957; files: src/channels/message/ingress-queue.ts, extensions/telegram/src/polling-session.ts, src/infra/restart-handoff.ts)
  • joshavant: Recent Telegram history includes spooled claim refresh and buffered replay fixes near the same user-visible stuck-ingress surface. (role: adjacent Telegram recovery contributor; confidence: medium; commits: db255b1154c1, 9921825e1795; files: extensions/telegram/src/polling-session.ts, extensions/telegram/src/telegram-ingress-spool.ts)
  • obviyus: Recent merged Telegram work narrows live-owned stuck claim recovery, overlapping the same durable Telegram ingress recovery family without replacing this startup sweep. (role: adjacent live-claim recovery contributor; confidence: medium; commits: dc09324ec2e1, d4819948f37d, 0b26a1bca728; files: extensions/telegram/src/polling-session.ts, extensions/telegram/src/telegram-ingress-spool.ts)
  • shakkernerd: Earlier restart-handoff commits introduced and hardened the supervisor restart handoff surface that this PR extends for sweep skipping. (role: restart-handoff feature history; confidence: medium; commits: acb0acd8dda4, 4a24b6dbc4d5, 0720c1f77dd2; files: src/infra/restart-handoff.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.
Review history (1 earlier review cycle)
  • reviewed 2026-06-21T19:07:04.790Z sha e30ce44 :: needs maintainer review before merge. :: none

@openclaw-barnacle 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 6, 2026
@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. mantis: telegram-visible-proof Mantis should capture Telegram visible proof. labels Jun 6, 2026
@clawsweeper
clawsweeper Bot temporarily deployed to qa-live-shared June 6, 2026 19:16 Inactive
@clawsweeper clawsweeper Bot added P1 High-priority user-facing bug, regression, or broken workflow. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. labels Jun 6, 2026
@openclaw-barnacle openclaw-barnacle Bot added scripts Repository scripts size: L size: M and removed size: M scripts Repository scripts size: L labels Jun 6, 2026
@849261680
849261680 force-pushed the worktree-fix-90945-sqlite-stale-claims branch from 0d839c2 to dc8f2c5 Compare June 6, 2026 20:46
@clawsweeper

clawsweeper Bot commented Jun 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

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

@849261680
849261680 force-pushed the worktree-fix-90945-sqlite-stale-claims branch from dc8f2c5 to 12cedda Compare June 6, 2026 20:55
@clawsweeper clawsweeper Bot added status: 🛠️ actively grinding The PR author has acted after the latest ClawSweeper review and work remains. and removed status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Jun 6, 2026
@clawsweeper

clawsweeper Bot commented Jun 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

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

@clawsweeper clawsweeper Bot added status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. and removed status: 🛠️ actively grinding The PR author has acted after the latest ClawSweeper review and work remains. labels Jun 6, 2026
@849261680

849261680 commented Jun 6, 2026

Copy link
Copy Markdown
Contributor Author

Added live gateway recovery proof (addresses the remaining needs proof [P1]).

Booted a real openclaw gateway process against an isolated state DB pre-seeded with a stuck claim left by a "crashed" session, and the startup sweep recovered it before channels started:

BEFORE boot: tg-msg-1 | status=claimed | claim_owner=999999999 (dead PID) | claimed 2 min ago

2026-06-07T05:08:37 [gateway] recovered 1 stale channel ingress claim(s) from previous session
2026-06-07T05:08:38 [gateway] http server listening (9 plugins: ...)
2026-06-07T05:08:38 [gateway] ready

AFTER boot:  tg-msg-1 | status=pending | claim_owner=null | last_error="recovered at startup: owner process gone"

This is the user-visible deadlock-clearing transition #90945 needs: the row left claimed by a dead owner is released to pending (deliverable again) at the next real gateway startup, before startChannels(). Ran with OPENCLAW_SKIP_CHANNELS=1 against an isolated OPENCLAW_STATE_DIR and a dev workspace, so no live Telegram credentials were needed and the recovery path itself is exercised by the real gateway boot. Full BEFORE/log/AFTER and the unit layer are in the updated PR body.

@clawsweeper re-review

@openclaw-barnacle openclaw-barnacle Bot removed the proof: supplied External PR includes structured after-fix real behavior proof. label Jun 6, 2026
@clawsweeper

clawsweeper Bot commented Jun 6, 2026

Copy link
Copy Markdown
Contributor

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

@openclaw-barnacle openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label Jun 6, 2026
@clawsweeper clawsweeper Bot added the mantis: telegram-visible-proof Mantis should capture Telegram visible proof. label Jun 18, 2026
@clawsweeper
clawsweeper Bot temporarily deployed to qa-live-shared June 18, 2026 21:08 Inactive
@clawsweeper clawsweeper Bot mentioned this pull request Jun 19, 2026
Closed
25 tasks
@openclaw-barnacle openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 19, 2026
@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. labels Jun 19, 2026
This was referenced Jun 19, 2026
Merged
Closed
Closed
Merged
Closed
Closed
@sunkencity999 sunkencity999 mentioned this pull request Jun 22, 2026
Closed
This was referenced Jun 24, 2026
Closed
Closed
Closed
Merged
Closed
@yaoyi1222 yaoyi1222 mentioned this pull request Jul 3, 2026
Closed
@clawsweeper clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jul 6, 2026
@charliemeyer2000 charliemeyer2000 mentioned this pull request Jul 13, 2026
Closed
@openclaw-barnacle

openclaw-barnacle Bot commented Jul 21, 2026

Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

cli CLI command changes gateway Gateway runtime mantis: telegram-visible-proof Mantis should capture Telegram visible proof. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. P1 High-priority user-facing bug, regression, or broken workflow. proof: sufficient ClawSweeper judged the real behavior proof convincing. proof: supplied External PR includes structured after-fix real behavior proof. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. size: L stale Marked as stale due to inactivity status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

channel_ingress_events (SQLite): stale claims never recovered after session crash — Telegram DM deadlocks

1 participant

@849261680