feat(dashboard): expose apply lane health telemetry#732
Conversation
|
@clawsweeper review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Codex review: needs real behavior proof before merge. Reviewed July 24, 2026, 6:45 PM ET / 22:45 UTC. ClawSweeper reviewWhat this changesThis PR adds signed apply-lane lifecycle telemetry, persists it in the dashboard StatusStore, exposes an apply-observability API and Overview card, and publishes non-blocking workflow observations with tests. Merge readiness⛔ Blocked until real behavior proof is added - 5 items remain Keep open. The prior producer-failure finding appears to have been addressed by the follow-up commits and focused workflow coverage, but this external dashboard/workflow feature still lacks inspectable after-fix proof that a real apply lifecycle posts both start and terminal observations and that the resulting API/card state is correct. Likely related people: Priority: P2 Review scores
Verification
How this fits togetherThe apply lane turns eligible review proposals into GitHub actions and durable state updates. This change adds a separate signed telemetry feed from that workflow into the dashboard’s Durable Object, where the Overview summarizes current apply health without new GitHub polling. flowchart LR
A[Apply workflow] --> B[Telemetry start event]
A --> C[Terminal apply result]
B --> D[Signed dashboard webhook]
C --> D
D --> E[Durable status store]
E --> F[Apply observability API]
F --> G[Overview health card]
Decision needed
Why: The patch adds a new operator-facing dashboard capability and workflow producer, so passing tests alone cannot establish whether this operational surface and its retained semantics are the desired long-term product boundary. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep the telemetry feed bounded and non-blocking, then merge only after a representative real apply run demonstrates signed start and terminal events reaching the API and Overview with correct freshness and throughput semantics. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR adds a new apply-lane observability capability rather than fixing a reported current-main failure. The relevant verification is a real apply lifecycle that emits and displays the new telemetry. Is this the best way to solve the issue? Unclear: the bounded, signed dashboard-local design is plausibly maintainable and avoids new GitHub reads, but it needs maintainer acceptance of the new operational surface and live proof of the complete producer-to-card path. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 3cb93c6a16bf. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (2 earlier review cycles) |
clawsweeper
Bot
added
merge-risk: 🚨 other
b306079 to
d532da0
Compare
d532da0 to
efb8de3
Compare
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: feat(dashboard): expose apply lane health telemetry This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
1 participant
Summary
Adds a compact, independently sourced Apply / close health card to the Overview. It is updated for the current bounded publication and State-writer architecture; it does not change review admission or result-publication behaviour.
Problem
After the recent ClawSweeper and
clawsweeper-staterecovery work, operators can see admission and publication telemetry but cannot reliably tell the difference between a currently running apply, a terminal apply, a proof-only failure before applying begins, and unavailable telemetry.Implementation
apply-observabilityv1 records in the dashboard StatusStore and servesGET /api/apply-observability?range=6h|24h|7d.in_progressobservation whenapply-existingactually begins, then a terminal observation after the current durable apply/state-publication flow completes.Current architecture and API load
This is dashboard-local telemetry: the Overview reads its Durable Object StatusStore and receives signed workflow posts. It adds no GitHub REST or GraphQL reads, no repository scan, and no workflow dispatch. It complements the current bounded batch publisher and State-writer model; #733 maps that changed publishing process into OpenClaw Bay's visual lanes.
Current-main review and CI repair
This branch was already based on current
main3cb93c6a16bf1209835942083ae9dd0ee8753184; the recovery PRs merged since the original work do not require a telemetry semantic change. The previously failedpnpm checkwas solelyoxfmton these six changed files. Commit2794703e4aa3a2849bfdbd697dbe15c9aada61d7applies that formatter output without changing behaviour.Validation
node --test --test-concurrency=1 test/apply-observability.test.ts- 13 passing.node --test --test-concurrency=1 test/dashboard-worker.test.ts- 189 passing.node --test --test-concurrency=1 --test-name-pattern="^review and apply primary boundaries ignore ledger-only failures$|^apply workflow bounds checkpoints and requeues with a fresh token$" test/sweep-workflow.test.ts- 2 passing structural workflow checks.pnpm exec oxfmt --check dashboard/apply-observability.ts dashboard/worker.ts scripts/publish-apply-observability.mjs test/apply-observability.test.ts test/dashboard-worker.test.ts test/sweep-workflow.test.ts- passing.pnpm run build:dashboardpnpm run lint:dashboardpnpm run lint:scriptsnode --check scripts/publish-apply-observability.mjsgit diff --checkThe repository-wide
pnpm run format:checkreports pre-existing checkout-wide CRLF/format noise on this Windows host. The focused formatter command above covers every PR file and is the same surface that caused the hostedpnpm checkfailure.The wider workflow-helper test path remains a pre-existing Windows-host limitation: its WSL relay does not provide
/bin/bash. This PR does not change platform policy or work around that unrelated Linux workflow test surface.Review closeout
codex review --uncommitted- clean; formatting-only, no actionable findings.git fetch origin && codex review --base origin/main- clean; no actionable correctness defects relative to current main.pnpm run review -- --local-range --target-repo openclaw/clawsweeper --base origin/main- read-only, no GitHub mutation,keep_open/ medium confidence, no discrete correctness or security finding. Reviewed current main through the prior semantic head; this final commit is formatter-only.Risks and rollout
The card remains
Awaiting produceruntil fresh signed telemetry arrives. Some producer fields intentionally stay unknown: the apply lane does not have a durable arrival/retry/dead-letter ledger, and terminal artifacts do not truthfully measure the live Actions queue. The workflow posts arecontinue-on-error, so telemetry cannot block apply/close work. Normal CI should provide one representative apply lifecycle proving both the start and terminal signed observations reach the dashboard API/health card.