Skip to main content
← Back to list
01Issue
BugTriagedSwamp CLIPublic
Assigneesstack72

Relationships

#2250 verify-build fails on the codegen-verify guard: 'No such key: stdout'

Opened by hammz · 9/17/2026

The codegen-verify job in swamp-extensions/verification/workflow-verify-build.yaml (lines 312 and 337) guards on:

${{ data.latest('build-detect-' + run.id, 'log').attributes.stdout.contains('CHANGED_CODEGEN: true') }}

The log data produced by the build-detect-* shell step has no stdout attribute, so guard evaluation throws and the whole workflow is reported as Failed:

InvalidExpressionError: Invalid expression: No such key: stdout
>  1 | data.latest('build-detect-' + run.id, 'log').attributes.stdout.contains('CHANGED_CODEGEN: true')

This happens on every verify-build run, including runs that change no codegen at all: codegen-verify fails in 0ms, its second step is skipped (dependency), and the workflow ends Failed even though setup, detect-changes, model-checks, upgrade-verify, extension-checks and cleanup all pass.

Seen while verifying lab#2245 (datastore/s3 + datastore/gcs change, no codegen touched): extension-checks ran S3 293 passed / GCS 279 passed and every other job completed, but the run still reported Failed.

The fix is in the guard expression — use whatever attribute actually carries the step's output (or gate on a data value the detect step writes explicitly) instead of attributes.stdout.

02Bog Flow
✓OPEN◉TRIAGED○IN PROGRESS○SHIPPED+ 1 MOREASSIGNEDCLASSIFICATION

Triaged

9/17/2026, 6:36:36 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack729/17/2026, 6:28:44 PM
Editable. Press Enter to edit.

hammz commented 9/17/2026, 6:04:31 PM

More detail after a second run (8ac34bb4-b7e2-4554-ab15-154155063d4e), with the guard changed locally to .content.contains('CHANGED_CODEGEN: true'):

  • The guard no longer throws, but codegen-verify still misfires on a branch that touches no codegen. codegen-check ran the full codegen quality gate (deno check downloading the codegen dependency tree), and then idempotency failed in 200ms with no log artifact written at all (swamp data get build-codegen-idem-<run> log → Data not found).
  • The detect step's log contains no CHANGED_CODEGEN line at all in this run (only CHANGED_DIR: datastore/gcs, CHANGED_DIR: datastore/s3), so the guard should have been false and both steps should have been skipped.

So there are two things here: attributes.stdout does not exist on a text/plain log record (per design/enablers/data-query.md, attributes is {} unless contentType is application/json), and .content is not a working substitute either. A reliable fix is probably for the detect step to write an explicit JSON data artifact (e.g. {"codegen": true|false}) and guard on attributes.codegen, rather than string-matching a log.

Sign in to post a ripple.