crates/dpp-dal/tests/passport_doc_compat.rs freezes one real stored doc per
shipped sector schema version and asserts each still reads through
Passport::from_stored under the dpp-domain this workspace builds against. It
is the only thing standing between a core bump and a node that can no longer read
its own database.
For battery it currently guards nothing.
Battery has no live coverage at all
Six battery fixtures exist, and after #108 all six are listed in
UNREADABLE_FIXTURES:
| Fixture |
Why it is excluded |
battery/v1.0.0.json |
No batteryType — required from v2.5.0, closed set, cannot be defaulted |
battery/v2.0.0.json |
No lens path to the current schema |
battery/v2.1.0.json |
Same chain gap |
battery/v2.2.0.json |
Same chain gap |
battery/v2.3.0.json |
Same chain gap |
battery/v2.4.0.json |
Lens path exists and refuses: batteryType predates the mandate |
every_frozen_passport_doc_still_reads continues on every one of them. The
sector with the most schema movement, the most fields, and the most regulatory
pressure has zero documents proving a bump does not break stored data.
The exclusions are individually correct — each is an accepted, permanent
compatibility break with a recorded reason, and dpp-domain refusing to invent a
regulatory classification is the right behaviour. The problem is only what is
left behind: the list grew to cover the whole sector, and nothing replaced it.
Three sectors have no fixture at their current version
The guard's own doc says to add a fixture "whenever a sector's schema_version
moves, captured from a real document, before bumping dpp-domain". Three moved
without one:
| Sector |
Current schema version |
Newest fixture |
| battery |
2.6.0 |
2.4.0 (unreadable) |
| textile |
1.2.0 |
1.1.0 |
| electronics |
1.2.0 |
1.1.0 |
The other eight sectors are at their current version.
Textile and electronics still have teeth — their v1.1.0 fixtures read through a
lens, so a future break in that path is caught. Battery does not.
Done when
- A fixture exists for battery 2.6.0, textile 1.2.0 and electronics 1.2.0.
every_frozen_passport_doc_still_reads exercises at least one readable battery
document.
Fixtures must be captured from a real document, not hand-written. A document
authored from the current struct deserialises back into that struct by
construction, so the guard would pass tautologically and catch nothing. Capture
means create + publish through the vault and take the stored doc, which is why
this needs a database and is not a desk exercise.
A worked capture path is worth landing with the fixtures — this recurs on every
schema bump, and the reason the gap opened is that there is no repeatable way to
close it.
Note
Adding a fixture at the current pin does not retroactively protect anything: the
guard "will not catch a bump that is already in Cargo.lock when the fixture is
added — it only catches the next one." That is the argument for doing it now
rather than at the next bump.
crates/dpp-dal/tests/passport_doc_compat.rsfreezes one real storeddocpershipped sector schema version and asserts each still reads through
Passport::from_storedunder thedpp-domainthis workspace builds against. Itis the only thing standing between a core bump and a node that can no longer read
its own database.
For battery it currently guards nothing.
Battery has no live coverage at all
Six battery fixtures exist, and after #108 all six are listed in
UNREADABLE_FIXTURES:battery/v1.0.0.jsonbatteryType— required from v2.5.0, closed set, cannot be defaultedbattery/v2.0.0.jsonbattery/v2.1.0.jsonbattery/v2.2.0.jsonbattery/v2.3.0.jsonbattery/v2.4.0.jsonbatteryTypepredates the mandateevery_frozen_passport_doc_still_readscontinues on every one of them. Thesector with the most schema movement, the most fields, and the most regulatory
pressure has zero documents proving a bump does not break stored data.
The exclusions are individually correct — each is an accepted, permanent
compatibility break with a recorded reason, and
dpp-domainrefusing to invent aregulatory classification is the right behaviour. The problem is only what is
left behind: the list grew to cover the whole sector, and nothing replaced it.
Three sectors have no fixture at their current version
The guard's own doc says to add a fixture "whenever a sector's
schema_versionmoves, captured from a real document, before bumping
dpp-domain". Three movedwithout one:
The other eight sectors are at their current version.
Textile and electronics still have teeth — their v1.1.0 fixtures read through a
lens, so a future break in that path is caught. Battery does not.
Done when
every_frozen_passport_doc_still_readsexercises at least one readable batterydocument.
Fixtures must be captured from a real document, not hand-written. A document
authored from the current struct deserialises back into that struct by
construction, so the guard would pass tautologically and catch nothing. Capture
means create + publish through the vault and take the stored
doc, which is whythis needs a database and is not a desk exercise.
A worked capture path is worth landing with the fixtures — this recurs on every
schema bump, and the reason the gap opened is that there is no repeatable way to
close it.
Note
Adding a fixture at the current pin does not retroactively protect anything: the
guard "will not catch a bump that is already in
Cargo.lockwhen the fixture isadded — it only catches the next one." That is the argument for doing it now
rather than at the next bump.