Skip to content

feat(compute): add workload revisions and deployment events list commands - #246

Merged
jbiskur merged 1 commit into
mainfrom
feat/compute-revisions-events
Aug 29, 2026
Merged

feat(compute): add workload revisions and deployment events list commands#246
jbiskur merged 1 commit into
mainfrom
feat/compute-revisions-events

Conversation

@jbiskur

@jbiskur jbiskur commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

Completes compute coverage. 4.7.0 shipped 21 of the 22 operations plus the SSE stream, but these two endpoints landed in compute-api 1.11.0, after 4.7.0 was cut:

  • GET /api/v1/workloads/{workloadId}/revisions
  • GET /api/v1/workloads/{workloadId}/events

The frontend currently declares both as local Command subclasses because the SDK had nothing. Those delete cleanly once this releases.

The detail most likely to be got wrong

outcome is optional on a revision, and it must be:

outcome: Type.Optional(ComputeOperationStatusSchema),

The service reports it at three levels of knowledge — the joined operation's status; pending when a revision names an operation that has not reported yet; and absent when it names no operation at all. That third case is every created revision, because a create mints no operation. Requiring the field would make parseResponseHelper throw on revision #1 of every workload in existence.

A test pins exactly that: a revisions page whose created entry carries no outcome, operationId or slotTier, asserted with assertEquals(response.revisions[2]?.outcome, undefined).

Shapes

Revisions are cursor-paginated — { workloadId, limit?, cursor? } in, { revisions, nextCursor? } out — matching the shipped runs-list command. Both responses are bare, not { success: true, ... } envelopes.

Events take no pagination: the cluster reaps them on roughly an hour's TTL, so the window is bounded by construction. An empty array is a legitimate answer for a healthy, quiet workload, and a test covers it. Each event carries name, type, reason, message, count and object { kind, name }, with source, firstSeen and lastSeen optional. type stays a plain string because the cluster's field is free-form.

Both use parseResponseHelper with a TypeBox schema rather than casting the raw response, and map 404 to NotFoundException, like every other command here.

Tests

248 → 254, 0 fail. Covers the no-outcome revision, cursor round-tripping, events spanning several object kinds including one with no source, an empty events array, and 404 for both.

lint, typecheck, test and build (ESM + CJS + DTS) all green.

🤖 Generated with Claude Code

…ands

`@flowcore/sdk` 4.7.0 shipped 21 of the 22 compute operations plus the SSE
log stream, but was cut before compute-api 1.11.0 added two read endpoints:

  GET /api/v1/workloads/{workloadId}/revisions
  GET /api/v1/workloads/{workloadId}/events

`ComputeWorkloadRevisionsListCommand` is cursor-paginated in the shape of the
shipped `ComputeWorkloadRunsListCommand`; `ComputeWorkloadEventsListCommand`
takes no pagination, because the Kubernetes event TTL already bounds the
window and an empty array is a legitimate 200.

`outcome` on a revision is DELIBERATELY optional, not a tolerance: upstream
reports the joined operation's status, `pending` when the named operation has
not reported, and NOTHING AT ALL when the revision names no operation. That
third case is every `created` revision — a create mints no operation — so a
required field would make `parseResponseHelper` throw on revision 1 of every
healthy workload. Pinned by a test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jbiskur
jbiskur merged commit 9afca59 into main Aug 29, 2026
2 checks passed
@jbiskur
jbiskur deleted the feat/compute-revisions-events branch August 29, 2026 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant