yasp-toolkit activity

Review what your jobs have been doing: every service publishes lifecycle events (created, update, completed, cancelled, failed) as work progresses, keyed by correlation id and task id.

The activity host defaults to https://compile.yasp.ai/activity and can be overridden with the --activity-* flags shown in --help.

Usage:

$ yasp-toolkit activity [OPTIONS] COMMAND [ARGS]...

Options: * --help: Show this message and exit.

Commands:

list: List activity events, newest first.
error-summary: Summarize failures as a daily histogram,...

`yasp-toolkit activity list`

List activity events, newest first.

Follows the server's cursor pagination until --limit events are collected, an event falls outside --max-age, or the pages run out.

Usage:

$ yasp-toolkit activity list [OPTIONS]

Option	Default	Description
`-c, --correlation-id <str>`	—	Only events for this correlation id.
`-e, --expand-correlation <str>`	—	Look up the correlation id of this task id, then list every event sharing it.
`--task-id <str>`	—	Only events attached to this task id.
`--payload-type <str>`	—	Only events with this payload type.
`--event-type <str>`	—	Only events with this lifecycle type (created, update, completed, cancelled, failed).
`--tag <str>`	—	Only events carrying this `key=value` tag; repeatable (e.g. `--tag env=prod --tag model=model1`).
`--show <str>`	—	Extra column to include in the table; repeatable. One of: correlation-id.
`--task-ids`	—	Print only the distinct task ids, one per line (newest first) — for piping into other commands.
`--limit <int range>`	`1000; x>=1`	Stop after this many events.
`--max-age <str>`	`7d`	Skip events older than this. `<number><unit>` with unit s/m/h/d/w (e.g. 30m, 12h, 7d).

`yasp-toolkit activity error-summary`

Summarize failures as a daily histogram, one row per message.

Walks failed events back --days days and draws how often each message failed on each day, oldest day left and newest right.

Usage:

$ yasp-toolkit activity error-summary [OPTIONS]

Option	Default	Description
`-d, --days <int range>`	`3; x>=1`	How many days back to scan.
`--payload-type <str>`	—	Only failures with this payload type.
`--tag <str>`	—	Only failures carrying this `key=value` tag; repeatable (e.g. `--tag env=prod --tag model=model1`).
`--limit <int range>`	`10000; x>=1`	Stop after scanning this many failures.
`--top <int range>`	`30; x>=0`	Show only the loudest N messages. 0 shows every row.

`activity list`

Each row shows the event's date (UTC), payload type, status, description, and task id — plus any extra columns requested via --show (e.g. --show correlation-id). A dim footer notes when the walk stopped early (--limit reached or events older than --max-age skipped).

`activity error-summary`

Walks failed events back --days days (3 by default) and draws how often each message failed on each day, oldest day left and newest right — for seeing when a pattern started and whether it is still going:

$ yasp-toolkit activity error-summary --days 31
2508 failures over 31 days, 118 patterns
┏━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┓
┃ Payload Type             ┃ Message                                   ┃ Per day (32)                     ┃ Total ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━┩
│ yasp.embedded.prepare.v1 │ Prepare failed                            │ _▁_▁▅▇▂_▁▁__▄▂▁_▆▄▄▃▃▂▁▁▂▁▂____▁ │   479 │
│ yasp.embedded.v1         │ Compile failed: compile exited with 1     │ _▂▁▃▂▃▁▁▁▁_▁▃▂▁▁▁▃▃▄▃▂▃▂▄▂▄__▁▁▁ │   422 │
├──────────────────────────┼───────────────────────────────────────────┼──────────────────────────────────┼───────┤
│ yasp.kernelgen.v1        │ Kernel generation failed: no optimized    │ ____▁▁▁▂▁▁▁▁___▂▁▃▂▂▁▁▁▁▁▁▁__▁_▁ │   154 │
│                          │ kernel produced: … min speedup <n>x       │                                  │       │
├──────────────────────────┼───────────────────────────────────────────┼──────────────────────────────────┼───────┤
│                          │ … 88 quieter patterns                     │                                  │     … │
├──────────────────────────┼───────────────────────────────────────────┼──────────────────────────────────┼───────┤
│                          │ All failures                              │ ▁▂▂▃▆▆▂▂▂▂▁▂▃▂▁▄▆▆▇▅▅▂▂▃▄▂▂▄_▁▁▂ │  2508 │
└──────────────────────────┴───────────────────────────────────────────┴──────────────────────────────────┴───────┘
one bar per day, 2026-08-10 (left) → 2026-09-10 (right); tallest pattern bar = 73 failures in a day;
All failures is scaled on its own, tallest = 230; showing the 30 loudest of 118 patterns

Rows run loudest total first. Narrow the scan with --payload-type and --tag the same way list does.

One scale for every pattern row, so bar height means the same thing on the quietest row as on the loudest — per-row scaling would draw a message that failed once a day as the day's worst outage. A day with no failures holds its column as a dim _. The blocks grow up from the floor of their cell, and _ is the one glyph flush with that floor — · floats mid-cell and . still sits above it, both breaking the line the bars are read against. It is dim where the bars are coloured, so the baseline never reads as the shortest bar; a quiet stretch stays visible as a gap; any failure at all draws at least ▁, so a rare day never reads as an empty one.

The All failures row closing the table is every failure in the window, including the patterns --top hid. It is scaled on its own — summing every pattern dwarfs any single one, so sharing the per-pattern scale would peg it at full height and say nothing — and the legend names both scales.

--top caps how many pattern rows are listed, 30 by default; --top 0 shows every row. The cap only ever hides listed rows: a … N quieter patterns line says how much was left out, the All failures total and shape still cover everything, and the bar scale is taken from every pattern so capping never rescales the bars.

Payload type is part of the grouping key as well as a column, so the same message raised by two services stays two rows — Compile failed: compile exited with 1 under yasp.embedded.v1 is counted apart from the identical message under yasp.embedded.v1.dev.

A message long enough to wrap spreads its row over several lines, and without something between rows there is nothing to say which count belongs to which message — so a rule is drawn on either side of each wrapped row. Rows that fit on one line are left undivided, including where they sit next to a wrapped one.

Bars stop at ▇ rather than a full █: block glyphs sit at the bottom of their cell, so a full-height bar would touch the filled bottom of the row above and weld two rows' strips into one shape. The reserved top eighth keeps every row's strip its own.

Messages are normalized before counting, so failures that differ only in a detail that varies per task land in one row:

Rule	Example	Why
URLs → `<url>`	`GET https://…/task_id%3D14c63d5c…/reference.pt2`	the per-task id inside would otherwise split one recurring fetch timeout across a dozen rows of count 1
IPv4 addresses → `<ip>`	`connection refused by 10.42.0.17`	the pod that answered varies per attempt; the port is kept
Stage directories → `<tmpdir>`	`--onnx=/tmp/yasp-launcher-vzykk_hb/model.onnx`	the per-run directory is randomly named; the file under it is kept
UUIDs → `<uuid>`	`Job 4ba31943-… ended with status failed`	catches the ids that appear outside a URL
Timestamps → `<ts>`	`"timestamp": "2026-08-31T00:30:59.954378Z"`	services paste structured logs into the description
Traceback line numbers → `line <n>`	`File "…/evaluator.py", line 338, in forward`	the line moves with any edit to that file; the file and function are kept
Durations → `<n>s` / `<n>ms`	`did not complete within 3600s`	the same failure whichever budget it blew
Integers of 5+ digits → `<n>`	`received 35799040 bytes, expected 121762907`	byte counts and offsets vary per transfer
Speedup thresholds → `<n>x`	`min speedup 0.01x`, `1x`	the same failure under a different threshold

Short integers are deliberately left alone: status codes (HTTP 403 vs 500), exit codes (compile exited with 1) and timeouts (within 3600s) are the failure's identity, not noise, so the digit floor sits at five. Everything else is grouped verbatim — use yasp-toolkit activity list --event-type failed to read messages unfolded.