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

Relationships

#1802 data catalog: multiple is_latest=1 rows per (model,data) — latest-demotion skips workflow step-output rows

Opened by justjoheinz · 8/24/2026· Shipped 8/25/2026

Summary

swamp data query / data.findByTag can return two rows for the same (model, data) instance because the data catalog holds multiple rows with is_latest = 1. swamp data versions <model> <name> recomputes latest from files and correctly shows one, so the two views disagree. Downstream this produces duplicated output — in our case, duplicate rows in a README generated from data.findByTag('specName','cheatsheet').

Environment

  • swamp 20260824.001920.0-sha.f0180ad4
  • Datastore: @webframp/gitlab-datastore v2026.08.21.2 (shared across two machines)
  • macOS (darwin 25.6.0)

Steps to reproduce / evidence

  1. Have a data instance that receives a compile-style model-method write (marked latest), then shortly after an approve workflow step-output write of the same spec (tags: source=step-output, workflow=…, step=approve).
  2. Query the catalog:
    SELECT model_name, data_name, COUNT(*)
FROM catalog WHERE is_latest=1
GROUP BY namespace, type_normalized, model_id, data_name
HAVING COUNT(*) > 1;
    In our repo this returned 9 instances, each with two is_latest=1 rows — always the model-method row + the approve step-output row.
  3. Run a fresh compile (model-method) on an affected instance. It demotes every prior model-method row to is_latest=0 but leaves the most-recent workflow step-output (approve) row still is_latest=1, and adds the new row as latest → still two latest rows. A workflow-step write appears to demote nothing at all.

Expected

Exactly one is_latest=1 per (namespace, model, data). A new write should demote all prior latest rows regardless of owner_type / source (model-method vs. workflow step-output).

Actual

is_latest demotion is effectively scoped by owner/source: model-method writes don't demote workflow step-output rows, and workflow-step writes don't demote prior rows. Approve/step-output rows accumulate as permanent additional latests.

Impact

  • Any consumer using data.findByTag / data query on latest gets duplicate records.
  • Recurs on every approve, so data-only cleanup does not hold — especially on a shared datastore where a second machine keeps writing.
  • No CLI command recomputes is_latest: gc (lifetime/version-cap only), datastore compact (vacuum), datastore migrate-index (index layout) don't, and data delete no longer has a --version flag (whole-artifact only), so there is no supported way to repair a corrupted catalog.
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 6 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/25/2026, 1:47:57 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/25/2026, 12:03:36 AM
Editable. Press Enter to edit.

stack72 commented 8/25/2026, 1:48:05 AM

Thanks @justjoheinz 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.