Skip to content

test: DB forward-compat regression test across TEE-VM releases#608

Open
kariy wants to merge 1 commit into
mainfrom
tee-db-test
Open

test: DB forward-compat regression test across TEE-VM releases#608
kariy wants to merge 1 commit into
mainfrom
tee-db-test

Conversation

@kariy

@kariy kariy commented Jun 19, 2026

Copy link
Copy Markdown
Member

Summary

Adds a CI regression test guarding database forward-compatibility across TEE-VM releases: a newer TEE-VM release must be able to open the database a previous release wrote. Follow-up to #601 (which made unsealed storage the default).

Why this is a katana-db test, not a VM test

Since #601 made unsealed storage the default, the TEE VM's data disk is an ordinary katana MDBX database on plain ext4 — the VM neither encrypts nor reshapes it, it just runs katana with a pinned --db-dir. So "DB forward-compat across TEE releases" reduces to the katana-db property "a newer katana opens an older katana's on-disk database", which can be exercised with two binaries on a Linux host — no QEMU, no SEV-SNP hardware.

What it does

misc/AMDSEV/scripts/test-db-forward-compat.sh:

  1. Fetches the katana bundled in the latest published TEE-VM release (katana-tee-vm-<tag>.tar.gz).
  2. With that old binary, writes a persistent DB and mines a few blocks (dev_generateBlock).
  3. With the current binary (built from this ref), opens the same --db-dir under --db.auto-migrate and asserts the chain survived: same chain id, block height not reset, and the old tip block is present.

It skips loudly when no katana-v* release exists yet, and fails on a real regression — e.g. a db-format bump without a migration, or MIN_OPENABLE_DB_VERSION rising above what shipped releases wrote. (--db.auto-migrate is required: without it a pending migration prompts interactively and would hang CI.)

Wiring

  • New tee-db-forward-compat job in .github/workflows/test.yml, gated like the existing db-compatibility-check (broader-rust) so it runs on the rust/db changes that actually regress forward-compat, and reuses the binary-ubuntu artifact (no extra katana build).
  • The script lives under misc/AMDSEV/ because it is TEE-release-artifact-aware (and is shellcheck-linted by amdsev-lint); the job lives in test.yml so it triggers on code changes, not only misc/AMDSEV edits.
  • docs/amdsev.md: cross-referenced from the forward-compat section.

Complements the fixture-based db-compat-test crate by pinning compatibility to the actual release cadence rather than a checked-in snapshot.

Verification

  • bash -n + shellcheck -S warning clean on the script; actionlint clean on the new job (pre-existing warnings elsewhere untouched).
  • This PR edits .github/workflows/test.yml, which is in both the workflow's trigger paths and the broader-rust filter — so the new job runs in this PR's CI, validating the script end-to-end against the current release.

🤖 Generated with Claude Code

A newer TEE-VM release must be able to open the database a previous release
wrote. With unsealed storage now the default, the VM's data disk is a plain
katana MDBX DB the VM neither encrypts nor reshapes, so this reduces to a
katana-db forward-compat check that needs no QEMU/SEV.

- misc/AMDSEV/scripts/test-db-forward-compat.sh: fetches the katana bundled in
  the latest published TEE-VM release (katana-tee-vm-<tag>.tar.gz), writes a
  persistent DB with it (mines blocks via dev_generateBlock), then opens the
  same --db-dir with the current build under --db.auto-migrate and asserts the
  chain survived: same chain id, block height not reset, old tip block present.
  Skips (loudly) when no katana-v* release exists yet; fails on a real
  regression (e.g. a db-format bump without a migration, or MIN_OPENABLE rising
  above what shipped releases wrote).
- .github/workflows/test.yml: new `tee-db-forward-compat` job, gated like
  `db-compatibility-check` (broader-rust) so it runs on the rust/db changes
  that actually regress forward-compat; reuses the binary-ubuntu artifact.
- docs/amdsev.md: cross-reference the test from the forward-compat section.

Complements the fixture-based `db-compat-test` crate by pinning compatibility
to the actual release cadence rather than a checked-in snapshot.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@codecov

codecov Bot commented Jun 19, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.60%. Comparing base (9bde0ae) to head (86d89be).
⚠️ Report is 454 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #608      +/-   ##
==========================================
- Coverage   73.32%   67.60%   -5.72%     
==========================================
  Files         209      337     +128     
  Lines       23132    46355   +23223     
==========================================
+ Hits        16961    31338   +14377     
- Misses       6171    15017    +8846     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant