Skip to content

Show legacy and unknown workflow version usage - #158

Draft
rmcdaniel wants to merge 3 commits into
mainfrom
cli/220-version-usage
Draft

rmcdaniel wants to merge 3 commits into
mainfrom
cli/220-version-usage

Conversation

@rmcdaniel

@rmcdaniel rmcdaniel commented Nov 14, 2026 •

Copy link
Copy Markdown
Member

Open runs can still depend on a version branch that an operator intends to remove. This draft adds dw workflow:version-usage <workflow-type> <change-id> --min-version=N, with namespace validation, all-state counts, a bounded page of runs, explicit unknown reasons, help and JSON/JSONL output.

The command uses relative GET /workflow-version-usage and requires literal capabilities.workflow_version_usage=true. It sends one usage GET and forwards opaque cursors without interpreting them. A first terminal page must contain the complete selected cohort; a continuation must fill the requested limit. Later terminal cursor pages may be empty while retaining all-state counts. Malformed responses, unavailable capability, auth/storage failures, redirects and lost replies remain failures.

Validation: all 14 actual-CLI/loopback tests pass locally under Rust 1.99, covering scope/query encoding, signed bounds, validation before HTTP, unknown reasons, response completeness, transport errors and offline help. In separate build targets, the predecessor source fails exactly the three new completeness controls (11 pass/3 fail), while the corrected source passes all 14. Current hosted Rust 1.86 checks remain required. The existing 25 parity-harness controls passed at the previous source checkpoint; the response-only correction leaves those surfaces unchanged.

The producer endpoint is not published yet. Actual native Server acceptance remains the final integration gate before this leaves draft; no release or shared #220 closure is claimed. The self-contained native dev Server in #160 remains the immediate delivery priority. CLI #157 stays set aside.

Refs durable-workflow/.github#220, durable-workflow/workflow#1146, durable-workflow/server#1221.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security source review HOLD on exact dc06274: response completeness is not closed against the producer contract.

The parser accepts a first terminal page whose echoed counts say total=5 but whose runs/returned_count contain only 4 entries and has_more=false. A focused causal control that removes one run from the otherwise-valid fixture and changes returned_count to 4 exits successfully and renders the truncated result. That can hide an open run while JSON/JSONL/human output still reports success.

For a first page (no cursor), a terminal page must contain the complete selected cohort: counts.total without a state filter, or that state count with a filter. Independently, has_more=true must return exactly the requested limit: the Server contract fetches limit+1 and truncates to limit when a continuation exists. Later terminal cursor pages should remain opaque; do not decode cursors or infer prior-page cardinality.

Please add causal controls for both incomplete first-terminal and undersized-continuation responses. Namespace/capability binding, exact echoed query checks, classification refusal, redirect refusal, and unknown-state presentation otherwise look sound in this bounded source review. No runtime, publication, or release disposition is implied.

@sonarqubecloud

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security re-review PASS for the bounded pagination correction at exact bf754f14df274ef7956831ac4342e5aad95af488 / tree 63f353b416027859e022a598c8c606436524ea4f.

This closes my incomplete-first-page finding:

  • On a first terminal page, returned_count must equal the selected cardinality: the all-state total without a filter, or the matching state count with a filter. A truncated first response therefore cannot emit successful counts.
  • Any page advertising has_more must contain exactly the requested limit rows. A short nonterminal page is refused.
  • A later terminal page reached through an opaque cursor may remain short or empty, because the v1 response does not expose the remaining cardinality. The updated positive test now exercises that case explicitly, and a zero-selected-count first page remains valid.

The existing checks still bind returned_count to the actual run-array length, cap it at the requested limit, constrain every returned run to the selected state, and prevent per-state observations from exceeding the signed counts. Together with the new first-page equality, this closes the earlier truncation path without inventing completeness for opaque later cursors.

The direct successor is limited to 12 production lines and the focused causal controls; git diff --check is clean. This is a source rebind only. The actual native endpoint/publication and remaining exact-head integration gates stay separate.

This branch has not been deployed

No deployments
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