Pulse Run-Event Catalog

Normative event catalog for Pulse: lifecycle, stage, scheduler, and diagnostic events. Severity, field set, retention contract.


On this page
  1. 1. Severity
  2. 2. Event record
  3. 3. Catalog
  4. Run lifecycle
  5. Stage
  6. Scheduler
  7. 4. Persistence contract
  8. Related

Pulse Run-Event Catalog

Pulse emits a structured event on every material run transition and on diagnostic conditions. Events are persisted per run and surfaced through the run-detail endpoint; event persistence is best-effort and never blocks the run itself.

This page is the event catalog and field contract. Architectural framing is in chapter 06; persistence is in schema.md §7.

Event-type identifiers are dot-separated and namespaced by subject (run., stage., schedule., lease.). New entries should follow the same convention.

1. Severity

data RunEventSeverity
  = RunEventInfo
  | RunEventWarn
  | RunEventError
  • info — ordinary lifecycle progress.
  • warn — degraded behavior that did not fail the run, or a recoverable scheduler decision.
  • error — the run or stage reached a failure state, or a persistence write failed.

2. Event record

Every event carries the fields below. event_type identifies the event; details is an event-specific JSON object.

FieldDescription
run_idRun identity.
event_typeOne of the catalog entries in §3.
severityinfo / warn / error.
messageHuman-readable description.
detailsOptional event-specific JSON.
created_atEvent timestamp.

Common details fields observed across events (present when applicable):

FieldDescription
stageStage identity (stage events).
error_typeError category (service-api.md §6).
next_run_atScheduler target time (schedule events).
outcomeRun-outcome tag (schedule events).

3. Catalog

Run lifecycle

event_typeSeverityEmitted when
run.completedinfoAll stages completed successfully.
run.failederrorScheduler observed an executor exception.
run.failed.settlederrorGraph settled with failures at the end of execution.
run.suspendedinfoRun suspended waiting on an external signal.
run.cancelledinfoTask cancelled by operator request.
run.shutdowninfoShutdown requested; executor stopping at a stage boundary.
run.stuckerrorFrontier empty but not all nodes settled (blocked-graph diagnostic).
run.graph_state_persist_failederrorGraph-state persistence write failed mid-run.
run.graph_state_stale_writewarnExecutor lost a graph-state CAS race and stopped without overwrite.

Stage

event_typeSeverityEmitted when
stage.completedinfoStage returned StageComplete.
stage.failederrorStage returned a terminal failure.
stage.skippedwarnStage skipped after retry exhaustion under ExhaustionSkipsStage policy.
stage.rewritteninfoStage emitted StageRewrite and the runtime admitted the proposal.
stage.rewrite_degradedwarnStage accepted degraded output after rewrite-budget exhaustion.
stage.worker_exception_reifiederrorAsync worker exception escaped spawnNodeWorker; reified into a node result.
stage.worker_exception_unattributederrorAsync worker exception escaped with no matching worker handle.
stage.cancel_before_retry_persist_failedwarnCancel-before-retry state failed to persist.

Scheduler

event_typeSeverityEmitted when
schedule.advancedinfoScheduler advanced next_run_at after run finalization.
schedule.restoredwarnOne-off task visibility restored (e.g. after failure) for manual retry.
lease.losterrorRun’s lease expired; scheduler observed the loss before reclaim.

4. Persistence contract

  • Persistence is best-effort: a write failure is logged and the run continues. Event history is supplementary observability and is never load-bearing for correctness.
  • Events are append-only once written; there is no update path.
  • Retention is governed at the schema level; callers should not depend on unbounded history.
  • Events are read through the run-detail API, not by querying the event table directly.

End of Pulse Run-Event Catalog.