fix(cron): route failure alerts to thread ids by azhangd · Pull Request #90887 · openclaw/openclaw

azhangd · 2026-06-06T08:51:05Z

Summary

Fixes [Enhancement]: failureAlert lacks threadId — per-cron failure alerts land in the wrong Telegram topic, forcing operators to watch an aggregate-only path #89848 by adding per-job failureAlert.threadId through cron schemas, CLI edit, storage, gateway send plumbing, and agent tool exposure.
Route announce failure alerts to the explicit thread id, or inherit the primary delivery thread only when channel, target, and account match.
Keep webhook failure alerts threadless and preserve invalid failure-alert fields for protocol validation.

Real behavior proof

Behavior addressed: cron failure alerts can store and preserve a Telegram topic/thread id separate from primary delivery.
Real setup tested: local dev Gateway with a temporary OpenClaw profile. No live Telegram send.
Steps run after the patch: added a cron with Telegram announce delivery using --thread-id 79; edited it with --failure-alert --failure-alert-after 1 --failure-alert-thread-id 79; ran cron get for the job.
Evidence: copied terminal output from pnpm openclaw cron get showed:

"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "-1001234567890",
  "threadId": 79
},
"failureAlert": {
  "after": 1,
  "threadId": 79
}

Observed result: the saved job kept both delivery.threadId and failureAlert.threadId as 79.
Not tested: live Telegram delivery.

Tests

node scripts/generate-kysely-types.mjs
pnpm docs:list
node scripts/run-vitest.mjs src/cron/service.failure-alert.test.ts src/cron/delivery.failure-notify.test.ts src/gateway/server-cron-notifications.test.ts src/gateway/server.cron.test.ts src/agents/tools/cron-tool.schema.test.ts src/agents/tools/cron-tool.test.ts src/cli/cron-cli.test.ts src/cron/store.test.ts src/state/openclaw-state-db.test.ts packages/gateway-protocol/src/cron-validators.test.ts src/cron/normalize.test.ts
pnpm exec oxfmt --check --threads=1 $(git diff --name-only origin/main)
git diff --check
codex review --base origin/main (addressed findings from completed runs; final rerun hit my local usage limit)

AI-assisted: yes.

clawsweeper · 2026-06-06T08:57:57Z

Codex review: needs real behavior proof before merge. Reviewed June 30, 2026, 1:11 PM ET / 17:11 UTC.

Summary
The PR adds per-job failureAlert.threadId across cron protocol/schema types, CLI edit flags, normalization, SQLite projection/storage, gateway send plumbing, agent tool schemas, docs, and focused tests.

PR surface: Source +242, Tests +502, Docs +2, Generated +2. Total +748 across 29 files.

Reproducibility: yes. source-level: current main and v2026.6.11 expose delivery.threadId but no equivalent failureAlert.threadId through the type, schema, resolver, storage projection, gateway send path, or docs. I did not run a live Telegram cron reproduction.

Review metrics: 1 noteworthy metric.

Cron Contract Surfaces: 1 public field, 1 CLI flag, 1 SQLite projection column added. The route crosses config/protocol, user CLI input, persisted storage, and message delivery, so maintainers need upgrade and compatibility confidence before merge.

Stored data model
Persistent data-model change detected: serialized state: src/cron/service/state.ts, serialized state: src/state/openclaw-state-db.generated.d.ts, serialized state: src/state/openclaw-state-db.ts, unknown-data-model-change: src/state/openclaw-state-db.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #89848
Summary: This PR is the active candidate fix for the canonical Telegram failure-alert thread-routing request; related failure-alert delivery/status reports share the surface but describe distinct failures.

Members:

canonical: [Enhancement]: failureAlert lacks threadId — per-cron failure alerts land in the wrong Telegram topic, forcing operators to watch an aggregate-only path #89848 - The PR body uses closing syntax for the issue that requests failureAlert.threadId for Telegram topic routing.
superseded: fix(cron): route failure alerts to configured threads #89869 - The earlier PR attempted the same thread-routing fix but is closed unmerged and replaced by this newer open candidate.
partial_overlap: [Bug]: failureAlert silently drops when cron stalls in runtime-plugins phase — lastFailureNotificationDeliveryStatus="unknown", operator never sees the failure #89847 - That issue mentions thread ids as a sub-ask, but its primary root cause is failure alerts being dropped during runtime-plugin stalls.
partial_overlap: failureAlert (after=1) never fires on 2026.6.5 — every errored run stuck at delivery_status 'not-requested' #92058 - That issue covers failure alerts not being requested or persisted, not Telegram topic routing.
partial_overlap: fix(cron): persist failure alert delivery status #95129 - That open PR targets failure-alert delivery-status persistence and does not replace this topic-routing work.

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

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
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] Add redacted live Telegram proof showing explicit and inherited failure-alert thread ids land in the intended topics.
Resolve the current merge conflicts against main and refresh the review result.
Document the account-id condition for inherited thread ids.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The supplied terminal proof shows local CLI persistence of failureAlert.threadId, but the PR changes visible Telegram topic delivery and explicitly says no live Telegram send was tested. 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.

Mantis proof suggestion
A Telegram Desktop proof would directly show whether failure alerts land in the intended topic instead of the default thread. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis telegram desktop proof: trigger cron failure alerts with explicit and inherited failureAlert.threadId values and verify each lands in the intended Telegram topic.

Risk before merge

[P1] The PR is draft and GitHub reports the branch as merge-conflicting/dirty, so maintainers need a fresh current-main merge result before treating the branch as landable.
[P1] The supplied proof shows local CLI persistence only and explicitly says no live Telegram send was tested, leaving the visible topic-routing behavior unproven.
[P1] The PR adds a public cron config/protocol field, CLI flag, and SQLite projection column, so upgrade compatibility and operator-facing behavior need maintainer approval even though the shape is additive.
[P1] The cron docs omit the account-id match required for inherited thread ids, which can mislead multi-account Telegram operators.

Maintainer options:

Refresh And Prove Topic Routing (recommended)
Resolve conflicts, update the inheritance docs, and add redacted live Telegram proof for explicit and inherited failure-alert topic delivery before merge.
Accept Local Persistence Proof
Maintainers may intentionally accept the local CLI, unit, schema, storage, and gateway evidence while owning the remaining live Telegram transport uncertainty.
Pause The Draft
Leave the draft open until a real Telegram environment and current-main merge result are available.

Next step before merge

[P1] Human review is needed because the remaining blockers are live Telegram proof, conflict resolution, docs correction, and compatibility approval rather than a safe autonomous repair.

Security
Cleared: No concrete security or supply-chain concern was found; the diff does not change dependencies, workflows, secrets handling, executable downloads, or credential storage.

Review findings

[P3] Document account matching for inherited threads — docs/automation/cron-jobs.md:228

Review details

Best possible solution:

Resolve conflicts, keep the additive schema/storage/gateway path, document the full inheritance rule including account id, and add redacted live Telegram topic-routing proof before maintainer compatibility approval.

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

Yes, source-level: current main and v2026.6.11 expose delivery.threadId but no equivalent failureAlert.threadId through the type, schema, resolver, storage projection, gateway send path, or docs. I did not run a live Telegram cron reproduction.

Is this the best way to solve the issue?

Yes for the primary direction: mirroring the existing delivery thread contract onto failure alerts is the narrow maintainable fix shape. The PR is not merge-ready until conflicts, live Telegram proof, docs, and compatibility review are handled.

Full review comments:

[P3] Document account matching for inherited threads — docs/automation/cron-jobs.md:228
The resolver inherits delivery.threadId only when the alert channel, normalized target, and account id match the primary announce delivery, but this docs sentence mentions only channel and target. Please include the account-id condition so multi-account Telegram users do not expect inheritance when a different bot/account prevents it.
Confidence: 0.88

Overall correctness: patch is correct
Overall confidence: 0.84

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: This is a bounded cron/Telegram routing improvement with real operator-message visibility impact but limited blast radius.
merge-risk: 🚨 compatibility: The PR adds a public cron config/protocol field, CLI flag, and persisted SQLite projection column that must remain upgrade-safe.
merge-risk: 🚨 message-delivery: The changed route determines whether failure-alert messages reach the intended Telegram topic or land in the wrong/default thread.
rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The supplied terminal proof shows local CLI persistence of failureAlert.threadId, but the PR changes visible Telegram topic delivery and explicitly says no live Telegram send was tested. 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.
mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The PR changes visible Telegram topic routing for cron failure-alert messages, which is suitable for a short Telegram Desktop recording.

Evidence reviewed

PR surface:

Source +242, Tests +502, Docs +2, Generated +2. Total +748 across 29 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	15	260	18	+242
Tests	10	517	15	+502
Docs	2	2	0	+2
Config	0	0	0	0
Generated	2	2	0	+2
Other	0	0	0	0
Total	29	781	33	+748

What I checked:

Live PR state and supplied proof: Live GitHub reports this PR open, draft, merge-conflicting/dirty, and at head 8a29d43; the PR body supplies copied local CLI persistence output and explicitly says no live Telegram send was tested. (8a29d432342b)
Current main type gap: Current main still defines CronFailureAlert with after/channel/to/cooldown/includeSkipped/mode/accountId and no thread/topic field. (src/cron/types.ts:211, f284ce3b4df7)
Current main resolver gap: Current main resolves failure alerts to channel, target, mode, and account only, so it never carries delivery.threadId into the alert request. (src/cron/service/failure-alerts.ts:65, f284ce3b4df7)
Current main gateway gap: Current main sendGatewayCronFailureAlert accepts channel/to/mode/accountId but no thread id, so the gateway alert path cannot select a Telegram topic. (src/gateway/server-cron-notifications.ts:180, f284ce3b4df7)
PR head implementation: PR head adds account-sensitive thread inheritance: explicit failure-alert thread ids win, webhook alerts ignore thread ids, and inherited delivery thread ids require matching channel, normalized target, and account id. (src/cron/service/failure-alerts.ts:83, 8a29d432342b)
PR head send plumbing: PR head forwards params.threadId into the failure-alert announce target sent by the gateway. (src/gateway/server-cron-notifications.ts:204, 8a29d432342b)

Likely related people:

0xbrak: Commit 4637b90 added configurable cron failure alerts, the policy surface this PR extends with a thread id. (role: introduced failure-alert behavior; confidence: high; commits: 4637b90c070f; files: src/cron/types.ts, src/cron/service.failure-alert.test.ts, src/cron/service/jobs.ts)
cwmine: The merged Telegram topic-routing PR for delivery.threadId is the sibling behavior this PR asks failure alerts to mirror. (role: sibling behavior contributor; confidence: medium; commits: 6776306387cc; files: src/cron/delivery.ts, src/cron/types.ts, docs/automation/cron-jobs.md)
kesor: Commit 4b4ea5d added failure-destination routing for failed cron jobs, adjacent to this failure-alert routing path. (role: adjacent feature owner; confidence: medium; commits: 4b4ea5df8bc1; files: src/cron/delivery.ts, src/cron/types.ts, src/gateway/server-cron.ts)
shakkernerd: Commit de952c0 split cron delivery planning from sending, and the PR reuses that delivery-plan boundary for thread inheritance. (role: recent delivery planning refactor author; confidence: medium; commits: de952c036abc; files: src/cron/delivery-plan.ts, src/cron/delivery.ts)
brunolorente: Commit ca76e2f added typed cron tool schemas, one of the public agent-tool surfaces this PR updates. (role: adjacent schema contributor; confidence: medium; commits: ca76e2fedc8e; files: src/agents/tools/cron-tool.ts, src/agents/tools/cron-tool.schema.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.

Review history (1 earlier review cycle)

reviewed 2026-06-21T18:16:40.074Z sha 8a29d43 :: needs real behavior proof before merge. :: [P3] Document account matching for inherited threads

azhangd · 2026-06-06T09:56:00Z

@clawsweeper re-review

clawsweeper · 2026-06-06T09:56:03Z

🦞🧹
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/27059214713
Updated: 2026-06-06T10:05:12.010Z

utk2103

changes are mentioned with description

openclaw-barnacle · 2026-07-21T04:33:42Z

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

clawsweeper Bot had a problem deploying to qa-live-shared June 6, 2026 09:07 Failure

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

azhangd force-pushed the fix/cron-failure-alert-thread-id branch from 8730c04 to f1cbb6a Compare June 6, 2026 09:54

utk2103 reviewed Jun 6, 2026

View reviewed changes

fix cron failure alert thread routing

8a29d43

azhangd force-pushed the fix/cron-failure-alert-thread-id branch from f1cbb6a to 8a29d43 Compare June 12, 2026 03:13

openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Jul 21, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(cron): route failure alerts to thread ids#90887

fix(cron): route failure alerts to thread ids#90887
azhangd wants to merge 1 commit into
openclaw:mainfrom
azhangd:fix/cron-failure-alert-thread-id

azhangd commented Jun 6, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

Uh oh!

azhangd commented Jun 6, 2026

Uh oh!

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

Uh oh!

utk2103 left a comment

Uh oh!

openclaw-barnacle Bot commented Jul 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Summary

Real behavior proof

Tests

Uh oh!

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

Uh oh!

Uh oh!

azhangd commented Jun 6, 2026

Uh oh!

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

Uh oh!

Uh oh!

utk2103 left a comment

Choose a reason for hiding this comment

Uh oh!

openclaw-barnacle Bot commented Jul 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

azhangd commented Jun 6, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading