#410 workflow-scope report's dataRepository.getContent returns null for data written in the same workflow run

Summary

A workflow-scope report's context.dataRepository.getContent(modelType, modelId, dataName, version) returns null for every data handle that an earlier step in the same workflow run wrote via context.writeResource(spec, key, body). The data is fully persisted: the catalog row exists for the exact (type_normalized, model_id, data_name, version) the report calls with, and the raw file is on disk. swamp data get <modelName> <dataName> returns the bytes immediately. Only the in-report dataRepository read fails.

findByName and findAllForModel exhibit the same behaviour, so all three documented read methods on the workflow-scope dataRepository are affected. The report's read pipeline cannot consume data its own workflow just produced.

Environment

• swamp 20260521.221703.0-sha.3f2b75f8
• macOS arm64
• Local file datastore (default)

Reproduction

1. Build a model extension whose method writes multiple resources across two specs per call:

   await context.writeResource("cluster", `cluster-${id}`, clusterBody);
   await context.writeResource("instance", `instance-${id}--${memberId}`, instanceBody);

2. Build a workflow-scope report that iterates step.dataHandles and reads each handle:

   for (const step of context.stepExecutions) {
     if (step.modelType !== "@me/my-model") continue;
     for (const handle of step.dataHandles ?? []) {
       const bytes = await context.dataRepository.getContent(
         step.modelType, step.modelId, handle.name, handle.version,
       );
       // bytes === null for every handle
     }
   }

3. Define a workflow that runs the model and requires the report:

   reports:
     require:
       - "@me/my-report"

4. Run: swamp workflow run my-workflow --input '{...}'.

5. Observe the report logs a "no bytes for X" warning for every handle, and inspect the catalog + disk to confirm the writes succeeded:

   sqlite3 .swamp/data/_catalog.db \
     "SELECT type_normalized, model_id, data_name, version, is_latest
      FROM catalog WHERE model_id='<step.modelId>'"
   # 44 rows, is_latest=1 on the latest version of each name
   
   ls .swamp/data/@me/my-model/<modelId>/<dataName>/<version>/raw
   # File exists, non-empty
   
   swamp data get my-model-name <dataName>
   # Returns the bytes successfully

6. Re-run the workflow without clearing anything — getContent still returns null for every handle on the second, third, ..., nth run. 5/5 consecutive runs from a clean state return 0 rows in the report.

Diagnosis

Side-channel logging inside the report confirms:

• step.modelType matches the value in the catalog's type_normalized column exactly.
• step.modelId matches the catalog's model_id exactly.
• handle.name matches the catalog's data_name exactly (cluster-<id> / instance-<id>--<member> keys, including the spec-name prefix).
• handle.version matches the catalog's version column exactly (number, not string).
• handle.specName is correctly populated; the report's iteration sees both cluster and instance handles.

Despite all four arguments matching the catalog row, getContent returns null. findByName(modelType, modelId, dataName, version) returns null. findAllForModel(modelType, modelId) returns an empty array — even when the catalog has 44 rows for that exact (type_normalized, model_id).

The dataRepository instance passed to the report exposes repoDir, catalogStore, markDirty, baseDir as own properties. The read methods are on the prototype and don't throw — they just return null/empty.

Offline replay confirms the read pipeline is correct

A standalone replay that:

• reads the persisted workflow-run-*.yaml,
• extracts step.output.dataHandles as step.dataHandles,
• and uses a custom dataRepository.getContent that reads ${baseDir}/${modelType}/${modelId}/${dataName}/${version}/raw via Deno.readFile,

renders the report's CSV with 100% correct row count and content. The report code is consuming the contract correctly; the runtime's dataRepository implementation is what returns null.

Expected behaviour

context.dataRepository.getContent(modelType, modelId, dataName, version) returns the bytes for any handle in step.dataHandles (for that step) whose catalog row exists. Same for findByName and findAllForModel.

Actual behaviour

getContent, findByName, findAllForModel all return null/empty regardless of whether the data was just written or has been persisted across previous runs. The catalog query and the runtime read of dataRepository are disconnected.

Impact

Workflow-scope reports that consume upstream models writing multiple resources per method call cannot read any of those resources. The misleading-but-superficial workaround is to shell out to jq over .swamp/data/<type>/<modelId>/<dataName>/latest/raw — which sidesteps the report system entirely but loses column ordering, dedup, and other in-report features. The user-facing report is effectively non-functional on the happy path, and the workflow shows succeeded, so the failure is silent unless the report itself logs a no-bytes warning.

Affected extensions (concrete repro)

• @jentz/aws-rds-inventory — model writes one cluster resource + N instance resources per list_clusters call.
• @jentz/aws-rds-inventory-csv — workflow-scope report that consumes the instance handles.

Both unpublished at the time of writing; loadable from local source paths via .swamp-sources.yaml. The report's smoke-test suite (which uses a synthetic dataRepository.getContent backed by an in-memory map) passes 37/37, so the bug is purely in the runtime's contract.

Extension code in PR 13

Workaround for users

jq over the on-disk JSON at .swamp/data/<modelType>/<modelId>/<handle.name>/latest/raw reproduces the report's row data without touching the report system.