Skip to main content
← Back to list
01Issue
BugClosedSwamp CLIPublic
AssigneesNone

Relationships

#2089 data.latest().attributes/.content unresolved in workflow assert/guard CEL for @mgreten/cli-agent extension data

Opened by kiljoy · 9/9/2026

Description

data.latest(modelName, specName) used inside a workflow assert step's expr (and presumably guard expressions generally) fails to resolve .attributes or .content on the returned record when the data was produced by the @mgreten/cli-agent extension model type (method invoke, dataOutputSpec specName: "invocation", kind: resource, contentType: application/json).

Both accessors fail with the same class of error:

Invalid expression: No such key: attributes
>    1 | data.latest("daily-note-agent", "invocation").attributes.success == true
Invalid expression: No such key: content
>    1 | data.latest("daily-note-agent", "invocation").content.success == true

data.latest(...) != null also evaluates false for this same modelName/specName pair — i.e. the function appears to resolve to null even though the record demonstrably exists (confirmed via swamp data get and swamp data query, both of which return the record's content fine).

The identical accessor pattern works correctly for a native command/shell model's result spec (kind: resource, same contentType) — both .attributes.<field> and cross-workflow lookups succeed there. So this is not a general data.latest()/CEL problem, it's specific to data produced by this one extension's model type (and possibly other third-party extensions — not tested further).

Steps to Reproduce

  1. Have a model of type @mgreten/cli-agent with at least one recorded invoke invocation (any prompt), e.g.:
    swamp model create @mgreten/cli-agent my-agent
swamp model @mgreten/cli-agent method run invoke my-agent --prompt "say hi"
  2. Confirm the record is queryable normally:
    swamp data query 'modelName == "my-agent" && specName == "invocation"' --select 'content.success' --json
# => returns [true] (or similar) — record and field both resolve fine here
  3. Create a minimal workflow with a single assert step:
    id: <assigned>
name: repro
jobs:
  - name: main
    steps:
      - name: check
        task:
          type: assert
          expr: >-
            data.latest("my-agent", "invocation").attributes.success == true
          message: repro
          severity: low
        dependsOn: []
        allowFailure: true
version: 1
  4. swamp workflow run repro --json

Expected: assert evaluates against the real record (passes since success: true).

Actual: step fails with Invalid expression: No such key: attributes. Substituting .content for .attributes produces the analogous No such key: content error. data.latest(...) != null alone evaluates to false.

Comparison (control case — works fine)

Same pattern against a command/shell model's result output:

expr: >-
  data.latest("some-shell-model", "result").attributes.stdout.contains("hello")

This resolves and evaluates correctly, including for records produced in a different workflow run than the one doing the querying (cross-workflow data.latest() lookup works fine for the native type).

Environment

  • swamp version: 20260825.013404.0-sha.59b73704
  • Extension: @mgreten/cli-agent (installed via swamp extension pull)
  • Platform: macOS (Darwin), local repo (not swamp serve)

Impact

This blocks using assert/guard-style CEL expressions to gate workflow steps (e.g. conditional retries) on the actual success/failure of a CLI-agent invocation, since the model's invoke method itself never throws on a failed underlying CLI call — it records exitCode/success in its output data instead of raising, by design (so failures are inspectable rather than opaque). Without a working data.latest() accessor, there's no supported way to branch a workflow on that recorded outcome; the only workaround found is routing through a command/shell step that re-queries the data via swamp data query and exits non-zero on failure, relying on native command/shell exit-code propagation to step status instead of CEL.

I did not dig into which of swamp core vs. the extension's dataOutputSpecs declaration is responsible — flagging as a swamp issue since data.latest() is swamp's own CEL binding and the same call shape behaves inconsistently across model types using swamp's own public API surface. Redirect to the extension if that's where the actual defect lives.

02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED

Closed

9/10/2026, 8:29:26 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

stack72 commented 9/10/2026, 8:29:25 PM

Hey @kiljoy

Thanks for the detailed report. This was a swamp-core data.latest() stale-cache issue, rather than an issue with @mgreten/cli-agent data output. It was fixed in v20260904.000159.0-sha.85da8268; please upgrade to that version or later.

Sign in to post a ripple.