#538·Instatic

[Bug]: Bundle import does not rebuild data_row_versions / active_version_id, leaving collection loops empty

Author: dend3Created Sep 17, 2026Updated Sep 17, 2026

Summary

When a site bundle is exported and later imported (restore), data_rows are recreated but no data_row_versions entries are created and active_version_id is never set. Any collection loop that renders rows (e.g. a projects grid on the homepage) resolves zero rows after a restore, even though every row exists in the admin with status: published.

Environment

  • Instatic v0.0.20 (commit f92e8dc)
  • Self-hosted via Coolify (built from source, ARM64)

Steps to reproduce

  1. On a site with a collection (table) and documents with status: published that are rendered via a loop component:
    • Export a site bundle (Backup → download .zip).
  2. Import that bundle into a fresh instance (or after wiping data).
  3. Import completes successfully — pages render, media works.
  4. Open the homepage: the collection loop renders nothing.
  5. In the admin, the documents are all still there and marked published.

Expected behavior

Import restores rows in a renderable state: each imported row should get a data_row_versions entry and its active_version_id should point to it, so loops resolve immediately without manual intervention.

Actual behavior

data_rows are inserted but the version chain is never rebuilt. Loops that resolve rows via active_version_id return 0 rows until each row is manually re-published.

Root cause (from source)

In the import path, rows are written via replaceDataRow (server/repositories/data/rows/import.ts). It inserts into data_rows (status, publishedAt, cells, …) but:

  • never inserts into data_row_versions, and
  • never sets active_version_id.

Related area: #534 (publish path producing active_version_id rows with site_snapshot_id = NULL) suggests this version-chain area is fragile in more than one way.

Workaround we use

Manually re-publish every imported document (content_set_document_status → published) and then call site_publish. That regenerates version rows and the loop renders again. It works, but for a site with many documents it is tedious and easy to miss — and nothing in the import result hints that anything is wrong.

Suggested fix

During bundle import, after inserting rows, either:

  1. create a data_row_version per imported row from the imported cells payload and point active_version_id at it, or
  2. persist and restore the original version chain in the bundle (export data_row_versions too, which would also make restores more faithful), or
  3. at minimum, detect rows with status = 'published' but no active version after import and surface a warning in the import report.