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

Relationships

#1878 Regression 20260826.004253.0: CEL data.latest()/data.version() throw in expressions — "Unresolved expression" for previously working models

Opened by 4chems · 8/27/2026· Shipped 8/27/2026

Since upgrading to 20260826.004253.0 (sha b64b034), every model whose globalArguments reference the data.* CEL functions fails to evaluate. Example (worked on 20260825-era version; the repo has 14 models with this exact pattern):

globalArguments:
  sshHost: `${{ data.latest("node-provisioner", inputs.nodeName).attributes.ipv4 }}`

Running any method now fails with:

Unresolved expression in globalArguments.sshHost: "${{ data.latest(\"node-provisioner\", inputs.nodeName).attributes.ipv4 }}"
code: method_execution_failed

Findings from isolation (filesystem datastore, macOS arm64):

  1. The data exists and is queryable: swamp data query with modelName == "node-provisioner" && name == "isoleucine" returns the record (isLatest: true), and swamp data get node-provisioner isoleucine --json returns its content. Only the CEL path fails.
  2. Literal arguments fail identically — ${{ data.latest("node-provisioner", "isoleucine").attributes.ipv4 }} with no inputs reference is also Unresolved, so it is not an inputs-scoping problem.
  3. Null-safe access does NOT rescue it: ${{ data.latest(...).?attributes.?ipv4.orValue("X") }} is still reported Unresolved — i.e. the function call itself errors rather than returning null/absent.
  4. data.version("node-provisioner", "isoleucine", 1) behaves the same.
  5. A static expression in the same position works: ${{ "[IP-1]" }} resolves and the method runs — the template engine itself is fine.
  6. swamp doctor datastores initially reported a partially missing catalog index (only for one unrelated model type); after --repair -y and a successful catalog rebuild the data.* failures persist unchanged.

Impact: all data-chaining between models via CEL is broken, which is the core wiring pattern the docs recommend (references/model/references/expressions.md). Current workaround is hardcoding values into model definitions, which defeats the data model.

Version: 20260826.004253.0-sha.b64b034d, filesystem datastore, repo with local_encryption vault. Happy to provide more diagnostics.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 6 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/27/2026, 8:17:57 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/27/2026, 7:59:05 PM
Editable. Press Enter to edit.

stack72 commented 8/27/2026, 8:18:14 PM

Hey @4chems, thanks for the detailed report — your isolation steps (literal arguments, null-safe access, static expression control) were really helpful in narrowing this down.

This is a confirmed regression introduced in 081ed81e (included in your build 20260826.004253.0). The new specName ambiguity detection we added to data.latest() had an overly broad guard — it fired on every lookup where the data item had a specName tag, even when you passed an exact data name like "isoleucine". For factory/fan-out models where one spec produces multiple named data items, the check falsely detected ambiguity and threw internally. The expression evaluator caught the error silently, leaving the ${{ }} template unresolved, which surfaced as the "Unresolved expression" error you saw.

The fix is already shipped in yesterday's v20260826.175216.0 (PR #2267, commit 88d26aa7). It narrows the ambiguity check to only fire when the lookup argument matches the specName — so exact data name lookups are no longer affected. Running swamp update should resolve all 14 models.

Sign in to post a ripple.