Historical implementation specification, preserved from revision 61e75e9. Requirements describe the work planned at that time, not current usage instructions. Original document.
Technical specification: align journal decoding with payload limits
1. Problem
Config.Validate permits enlarged limits up to absolute ceilings. The writer and staged reader use the effective Config, but the journal decoder hardcodes the default 256 MiB/1 GiB limits. A valid large-asset transaction can commit yet fail to recover after a crash with the same configuration.
The problem was found during the audit of v0.2 computation assets but is a general durability bug.
2. Requirements
Choose and document one contract:
The decoder checks the manifest against immutable absolute ceilings without payload I/O, then readStagedJournal applies the effective Config; or
The decoder accepts explicitly supplied immutable effective limits.
Do not:
weaken overflow, ordinal or tamper checks;
read payload before manifest, provenance and limit validation;
change the journal v5 wire format unnecessarily;
allocate hundreds of MiB merely for a test fixture.
3. Files
store/fs/fs.go;
store/fs/staged_payload_limits_test.go;
a focused recovery integration test.
4. Tests
All tests use AAA.
A manifest above defaults but below the absolute ceiling passes the decoder stage.
A smaller configuration on reopen rejects recovery before payload I/O.
The same enlarged configuration recovers successfully.
Aggregate and size overflow are rejected.
Ordinal, tamper and missing-payload contracts do not regress.
Use a bounded unit fixture instead of a real 256+ MiB allocation.
5. Acceptance criteria
The writer and recovery accept the same valid configured transaction.
A smaller policy safely blocks recovery before payload reads.