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-datastorev2026.08.21.2 (shared across two machines) - macOS (darwin 25.6.0)
Steps to reproduce / evidence
- Have a data instance that receives a
compile-style model-method write (marked latest), then shortly after anapproveworkflow step-output write of the same spec (tags:source=step-output,workflow=…,step=approve). - Query the catalog:
In our repo this returned 9 instances, each with twoSELECT model_name, data_name, COUNT(*) FROM catalog WHERE is_latest=1 GROUP BY namespace, type_normalized, model_id, data_name HAVING COUNT(*) > 1;is_latest=1rows — always the model-method row + theapprovestep-output row. - Run a fresh
compile(model-method) on an affected instance. It demotes every prior model-method row tois_latest=0but leaves the most-recent workflow step-output (approve) row stillis_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 queryon 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, anddata deleteno longer has a--versionflag (whole-artifact only), so there is no supported way to repair a corrupted catalog.
Shipped
Click a lifecycle step above to view its details.
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.