Summary
After #948 lands and the refinery cutover has been exercised in a release, we should do a follow-up cleanup pass on the database schema and migration UX.
#948 intentionally keeps the one-time cutover boring and low-risk:
- it preserves the legacy
metadata columns
- it keeps the old additive shape instead of rebuilding
metadata
- it leaves some post-cutover cleanup and UX polish for later
That is the right trade during the migration-system replacement, but it leaves cleanup debt that should be addressed once refinery is the normal path.
Goals
1. Canonicalize the metadata table
Move metadata to the real post-cutover shape instead of keeping compatibility baggage indefinitely.
Expected scope:
- remove dead legacy columns such as
schema_version and domain_type
- update
anchor/database/src/sql_operations.rs INSERT_METADATA
- update
anchor/database/src/schema.rs ensure_metadata_row
- make sure fresh and migrated DBs converge to the same canonical latest schema
- keep or extend migration tests to cover the cleanup path
2. Revisit the max_operator_id_seen semantics explicitly
Right now the cutover intentionally uses:
- fresh DB:
max_operator_id_seen = 0
- adopted schema-v1 DB:
max_operator_id_seen = NULL
That is acceptable for the cutover because schema v1 never tracked the field, but it is subtle.
Follow-up should explicitly decide whether to:
- keep the current
NULL sentinel semantics and document them as final, or
- replace them with a less implicit representation if we want to remove sentinel-style behavior
Whatever we choose, the meaning should be obvious from the final schema and code.
3. Tighten refinery-managed migration UX and tests
Once refinery is the established path, we should tighten the remaining UX/test debt around refinery-managed DBs.
Expected scope:
- add explicit downgrade / future-migration coverage for refinery-managed DBs
- decide whether raw refinery missing-version errors should be surfaced directly or mapped to Anchor-specific guidance
- keep recovery-path tests for partial startup states so restart behavior stays intentional
Context
The current code shape after #948 is intentionally transitional. This follow-up is for simplifying the post-cutover steady state, not for widening the initial migration risk.
This should happen after the refinery cutover has landed and been exercised, not as part of the initial migration-system replacement.
Summary
After
#948lands and the refinery cutover has been exercised in a release, we should do a follow-up cleanup pass on the database schema and migration UX.#948intentionally keeps the one-time cutover boring and low-risk:metadatacolumnsmetadataThat is the right trade during the migration-system replacement, but it leaves cleanup debt that should be addressed once refinery is the normal path.
Goals
1. Canonicalize the
metadatatableMove
metadatato the real post-cutover shape instead of keeping compatibility baggage indefinitely.Expected scope:
schema_versionanddomain_typeanchor/database/src/sql_operations.rsINSERT_METADATAanchor/database/src/schema.rsensure_metadata_row2. Revisit the
max_operator_id_seensemantics explicitlyRight now the cutover intentionally uses:
max_operator_id_seen = 0max_operator_id_seen = NULLThat is acceptable for the cutover because schema v1 never tracked the field, but it is subtle.
Follow-up should explicitly decide whether to:
NULLsentinel semantics and document them as final, orWhatever we choose, the meaning should be obvious from the final schema and code.
3. Tighten refinery-managed migration UX and tests
Once refinery is the established path, we should tighten the remaining UX/test debt around refinery-managed DBs.
Expected scope:
Context
The current code shape after
#948is intentionally transitional. This follow-up is for simplifying the post-cutover steady state, not for widening the initial migration risk.This should happen after the refinery cutover has landed and been exercised, not as part of the initial migration-system replacement.