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

Relationships

#571 data get/list --workflow and workflow history get/logs cannot resolve extension-delivered workflows (Workflow not found)

Opened by jdh313 · 6/6/2026· Shipped 6/6/2026

Summary

swamp data get --workflow, swamp data list --workflow, and swamp workflow history get/logs fail with Workflow not found: <name> for any workflow delivered by a pulled extension (e.g. @swamp/kubernetes/cluster-health). The same commands work for repo-local workflows. Execution is unaffected — workflow run/get/list resolve extension workflows fine — so a user can run an extension workflow successfully and then be unable to retrieve its data through any workflow-scoped CLI path. The retrieval commands that swamp itself prints in the post-run output are the ones that fail.

Steps to reproduce (clean room)

  1. swamp init . in an empty directory
  2. swamp extension pull @swamp/kubernetes
  3. swamp workflow run @swamp/kubernetes/cluster-summary (any extension workflow; even a run with failed steps produces the @swamp/workflow-summary report artifact)
  4. Retrieval fails by name AND by UUID:
$ swamp data list --workflow @swamp/kubernetes/cluster-summary
Error: Workflow not found: @swamp/kubernetes/cluster-summary

$ swamp data get --workflow @swamp/kubernetes/cluster-summary report-swamp-workflow-summary
Error: Workflow not found: @swamp/kubernetes/cluster-summary

$ swamp data list --workflow eaea8dd8-54f0-4d86-ab75-68bd3dd5ec1b
Error: Workflow not found: eaea8dd8-54f0-4d86-ab75-68bd3dd5ec1b
  1. Control — a repo-local workflow retrieves fine with the identical commands (swamp workflow create test-wf ..., run it, then swamp data get --workflow test-wf <data> works).

Reproduced on a pristine repo; swamp doctor extensions reports a healthy catalog. Not environmental. Also verified the artifacts ARE persisted correctly on disk under .swamp/data/workflow/<workflow-uuid>/<data-name>/<version>/raw — only the resolution step fails.

Root cause

The deps factories on the data-retrieval paths construct a bare repo-local workflow repository instead of the composite one:

  • src/libswamp/data/get.ts (createDataGetDeps): const workflowRepo = new YamlWorkflowRepository(repoDir);
  • YamlWorkflowRepository scans only <repo>/workflows/workflow-*.yaml (yaml_workflow_repository.ts, baseDir default join(repoDir, "workflows")); extension workflows live under .swamp/pulled-extensions/<ext>/workflows/ and are invisible to it. findById also builds the local path directly, which is why UUID lookup fails too.
  • The working commands (workflow run/get/list) resolve through CompositeWorkflowRepository(yamlRepo, ExtensionWorkflowRepository) built in repository_factory.ts::createRepositoryContext — the data paths never get that composite.

Same bare new YamlWorkflowRepository(repoDir) construction on these read paths:

  • src/libswamp/data/get.tsdata get --workflow
  • src/libswamp/data/list.tsdata list --workflow
  • src/libswamp/workflows/history_get.tsworkflow history get
  • src/libswamp/workflows/history_logs.tsworkflow history logs
  • (src/libswamp/reports/search.ts and src/cli/completion_types.ts look similar but I did not repro those surfaces)

Suggested fix: have these deps factories accept/construct the same composite repository the factory already provides.

Note: workflows/delete.ts shares the construction, but local-only there is arguably correct (extension workflows are read-only by design) — though it fails with Workflow not found rather than a "read-only / managed by extension" message.

#337 ("Workflow-scope report artifacts unreachable via swamp data get --workflow", shipped) fixed the same command surface one layer deeper — report artifacts missing from step dataArtifacts after the workflow name resolved. This issue is upstream of that: for extension workflows, name resolution itself fails, so the #337 fix is unreachable.

Environment

  • swamp 20260605.223149.0-sha.ff10af58 (also repro'd on 20260523.014309.0)
  • macOS (darwin), filesystem datastore
  • Source inspected via swamp source fetch at the matching version

Workaround

swamp data query 'ownerRef == "<workflow-uuid>" && name == "<data-name>"' --select content reaches workflow-scope artifacts; step outputs are reachable via swamp data query 'workflowName == "@ns/wf" && name == "<data>"' --select content or model-scoped swamp data get <model> <name>.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

6/6/2026, 10:19:29 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack726/6/2026, 9:30:37 PM
Editable. Press Enter to edit.

stack72 commented 6/6/2026, 10:19:40 PM

Thanks @jdh313 for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.