mirror of
https://github.com/mulgadc/spinifex.git
synced 2026-10-15 09:01:31 +00:00
b73ab7cfb3
* fix: assert the takeover against the volume that was actually left unsealed TestCrossNodeStartAfterFailedSealTakesOverLoudly picked its subject in advance — the attached pattern volume — and treated the stop returning an error as proof that volume's seal had failed. It is not. The unmount is a NATS request, and the caller giving up says nothing about the seal behind it; local state kept with no seal receipt is equally what an in-flight seal looks like. In the nightly the test then thawed predastore, the pattern volume's seal finished against a backend that was answering again, and the marker cleared. By the time the volume moved there were no unsealed writes, so viperblock was right to say nothing and the test failed it as a silent loss. The product was loud where it mattered. The instance's root volume has to read its AMI snapshot to seal, which the freeze does break, so its seal genuinely failed and the node it landed on logged the takeover naming the node that had been holding the writes. A blank attached volume has no such read and can seal straight through the outage. So the test now reads which volumes the cluster records as unsealed, after the thaw has settled rather than before, and asserts the takeover against those. If nothing was left behind it skips: the fault injection did not reproduce, and asserting a warning there would be asserting a wrong one. * fix: publish the instance cache resync mark with its readiness, not after it installSync set ready under c.mu and markResynced ran after the unlock, so there was a window where the cache was ready and serving records while resyncAge reported that no sync had ever succeeded. A caller that observes a ready cache and then asks how stale it is got "never", which reads as a cache that cannot be trusted, and the resync-age metric was skipped for as long as the window lasted. The mark now goes up under the same lock that publishes readiness, so any reader that takes the lock and sees a ready cache sees the mark too. Both callers dropped their trailing markResynced, which installSync now does. Widened under the race detector, which is where TestPeriodicResync_Undecodable RecordMarksDegraded had been failing intermittently: it reads resyncAge straight after waiting for readiness.