Skip to main content

Module storage_conformance

Module storage_conformance 

Source
Expand description

A portable conformance suite for ProtocolStateStorage implementations.

Swappable storage is only a property if it can be verified. Without a suite, “bring your own backend” is a promise: an adapter that looks right and returns Ok from every method can still lose records under an overwrite, leak keys between categories, or truncate a value at some internal limit, and the symptom arrives much later as data that quietly is not there.

Green here is the definition of “this backend is supported”.

The suite drives the trait directly rather than going through the sealing chokepoint, because what is under test is the adapter’s contract: bytes in, the same bytes out, addressed by (key_type, key_id). It writes only under its own key types, and deletes everything it wrote.

Key-type isolation is checked first, with point writes and point deletes of ids nothing else uses, and a failure ends the run there. Every listed delete after it trusts that listing a probe key type names only probe records; on a backend that merges key types it names real records too, and the cleanup would delete them. That makes the suite safe to run against a live store whatever the backend does with key types. It is not a promise for every defect: probe a new backend on a scratch instance until it is green.

Structs§

ConformanceFailure
The report types are the MLS suite’s, re-exported, so the two suites render one JSON shape and one reader serves both. One failed check.
ConformanceReport
The report types are the MLS suite’s, re-exported, so the two suites render one JSON shape and one reader serves both. The result of running a suite against one backend.

Constants§

CONFORMANCE_KEY_TYPE
The key type every probe record is written under.
CONFORMANCE_KEY_TYPE_OTHER
A second key type, used to prove categories do not bleed into each other.

Functions§

run
Run the suite.
run_json
Run the suite and render the report as JSON.