Update 1: Hardening the Core: Self Healing Storage and Reverse DAG Watch Mode
When we thought ZEPHYR 2.0 was ready for final packaging, we took a step back and conducted an external architectural audit using our evaluation agent. We asked ourselves some uncomfortable questions:
What happens if an operating system process terminates abruptly mid write during a massive build? What happens if a cached binary suffers silent bit rot on disk? And what happens when modern editors fire bursts of temporary atomic save events?
Instead of leaving those edge cases to chance, we engineered three major architectural upgrades into the core engine:
1. Crash Atomic CAS Durability
We added explicit tmpFile.Sync() flushing before atomic os.Rename operations across all blob writes in our Content Addressable Store (CAS). This ensures file buffers are fully committed to physical media before receiving their content addressable key, eliminating partial writes during sudden power loss or process kill signals.
2. Verify on Read and Self Healing Quarantine
In CASStore.RestoreBlob, ZEPHYR now validates the cryptographic SHA-256 digest on read. If a cached blob on disk has been modified or corrupted, ZEPHYR isolates the file into .taskcache/quarantine/<hash>.bad.<timestamp> and flags the entry. Rather than crashing or propagating a bad binary, the task executor automatically invalidates the stale Action Cache manifest, logs [SELF-HEAL] Recompiling task from scratch..., and performs a clean recompilation.
[SELF-HEAL] Detected corrupted CAS blob: 6fe25d5... (quarantined)
[SELF-HEAL] Stale Action Cache invalidated. Recompiling task cleanly...
[build] [OK] in 1.34s (Self-healing completed successfully)
Log in or sign up for Devpost to join the conversation.