OSS-Singularity/zcode-dispatch-observatory
OSS-Singularity/zcode-dispatch-observatory
Watch
1
0
Fork
You've already forked zcode-dispatch-observatory
 0
Code Issues Pull requests Projects Releases 137 Packages Wiki Activity Actions

Dispatch lifecycle visibility: pending strip + presumed-dead surfacing (v1.18.0) #42

Merged
ClaudiuSchuster merged 1 commit from oss-oo/observatory-lifecycle-p-nkyp20260925 into main 2026-09-25 13:39:50 +00:00
Conversation 0 Commits 1 Files changed 4 +344 -1
ClaudiuSchuster commented 2026-09-25 13:37:10 +00:00
Owner

Motivated by three silent dispatcher deaths in one day (2026-09-25) that were only noticed because the Running table went empty. Pairs with zcode-dispatch v0.3.4 (merged, released, installed) whose lifecycle ledger feeds this round.

Pending strip. A slim strip above Running lists lifecycle-ledger entries without a live session yet: chips with project/model/age and a breathing dot. Normal state: seconds while the app-server boots the session, then the chip resolves as the session appears in Running.

Anomaly states. Pending > ZDO_PENDING_DISPATCH_MS (120 s default) → AMBER glow. Presumed-dead (reaper flagged the process gone without a terminal state) → RED glow, copy buttons for the cwd and result-file path so the owner can hand the creator session the trail, and the row STAYS until dismissed (✕ — observatory-local state in observatory-state.json, pruned when the ledger cap ages the id out; the ledger itself is read-only here). Completed dispatches are not shown; no ledger (older dispatcher) → empty strip.

API: /api/sessions gains dispatches; new POST /api/dispatch/dismiss.

Verification: unit tests for the row derivation (pending/amber/red precedence, dismissal, garbage tolerance, state pruning — 11 tests green); live CDP DOM probes in a real headless browser confirmed chip classes, copy payloads, and dismissal across a full reload; Super-Linter green on the verified lane set (BASH/BASH_EXEC/MARKDOWN/PYTHON_PYLINT/PYTHON_RUFF/YAML).

README: lifecycle paragraph (fired → pending → running → done/presumed-dead) and what each glow means.

Motivated by three silent dispatcher deaths in one day (2026-09-25) that were only noticed because the Running table went empty. Pairs with zcode-dispatch v0.3.4 (merged, released, installed) whose lifecycle ledger feeds this round. **Pending strip.** A slim strip above Running lists lifecycle-ledger entries without a live session yet: chips with project/model/age and a breathing dot. Normal state: seconds while the app-server boots the session, then the chip resolves as the session appears in Running. **Anomaly states.** Pending > `ZDO_PENDING_DISPATCH_MS` (120 s default) → AMBER glow. Presumed-dead (reaper flagged the process gone without a terminal state) → RED glow, copy buttons for the cwd and result-file path so the owner can hand the creator session the trail, and the row STAYS until dismissed (✕ — observatory-local state in observatory-state.json, pruned when the ledger cap ages the id out; the ledger itself is read-only here). Completed dispatches are not shown; no ledger (older dispatcher) → empty strip. **API**: `/api/sessions` gains `dispatches`; new `POST /api/dispatch/dismiss`. **Verification**: unit tests for the row derivation (pending/amber/red precedence, dismissal, garbage tolerance, state pruning — 11 tests green); live CDP DOM probes in a real headless browser confirmed chip classes, copy payloads, and dismissal across a full reload; Super-Linter green on the verified lane set (BASH/BASH_EXEC/MARKDOWN/PYTHON_PYLINT/PYTHON_RUFF/YAML). **README**: lifecycle paragraph (fired → pending → running → done/presumed-dead) and what each glow means.
Dispatch lifecycle visibility: pending strip + presumed-dead surfacing (v1.18.0)
All checks were successful
Checks / Functional checks (pull_request) Successful in 15s
Details Explain this check
2f421439bb 
A slim PENDING DISPATCHES strip above Running reads zcode-dispatch
v0.3.4's lifecycle ledger (stream-dispatches.json) and shows the phase
the session tables cannot see: fired-but-not-running dispatches as
chips (project, model, live age, breathing dot) that resolve by
themselves within seconds when the app-server boots the session.

Anomaly states: a chip still pending past ZDO_PENDING_DISPATCH_MS
(120 s default) glows AMBER; a presumed-dead entry (the sweeper's
reaper found the dispatcher process gone without a terminal state)
glows RED, carries the trail with copy buttons (cwd, result-file
path) for whoever investigates, and STAYS until dismissed (✕,
observatory-local state, pruned when the ledger's 200-entry cap ages
the id out). Terminal and session-bearing entries are never shown —
the session tables tell that story; an absent ledger (older
dispatcher) keeps the strip empty.

Verified in a real browser via CDP DOM probes (chip classes, copy
payloads, dismissal through a full reload); unit tests cover the row
derivation (pending/amber/red, dismissal, garbage tolerance, state
pruning). README documents the fired → pending → running →
done/presumed-dead lifecycle and what each glow means.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
OSS-Singularity/zcode-dispatch-observatory!42
No description provided.