Related to this comment.
Currently, the methods that update the Store (e.g., writing the config, manifest, and tags) are not atomic.
If an error occurs in between these steps, for example, after writing the config but before the manifest or tags are persisted, the store may be left in an inconsistent or partially written state.
This can result in:
- Dangling references or incomplete entries in the store.
- Subsequent operations (reads, pushes, or deletions) failing unexpectedly.
- Difficulty in recovering or cleaning up after a failed write.
Proposed solution
- Make the update operation atomic, either all store updates succeed, or none are persisted.
- Alternatively, implement a rollback mechanism to clean up any partially written data if an intermediate step fails.
- Add tests simulating mid-operation failures to verify that the store remains consistent after recovery.