David Snelling
7feba49d94
With the unique per-writer temp suffix, a rename ENOENT can no longer mean "a concurrent idempotent writer already renamed it" — nobody else holds this writer's temp. It means our just-written temp vanished before the rename, so the bytes did NOT land. The old code returned success on that ENOENT, acknowledging a write that persisted nothing; the native provider mmaps these blobs, so a phantom-acked blob is a silent-loss. saveBinaryBlob now retries once with a fresh temp (self-healing a transient external-sweeper/crash-cleanup race), and if the temp vanishes again it throws loud rather than acknowledging a store-nothing write. Non-ENOENT rename faults propagate verbatim as before. The unique-temp suffix already eliminated the concurrent same-key collision that originally motivated the ENOENT shortcut. |
||
|---|---|---|
| .. | ||
| blob-save-durability.test.ts | ||
| blobStorage.compression-policy.test.ts | ||
| blobStorage.test.ts | ||
| clear-native-footprint.test.ts | ||
| getNouns-totalCount.test.ts | ||
| getVerbs-totalCount.test.ts | ||
| sharding-new-installation-log.test.ts | ||
| sharding.test.ts | ||
| stats-count-accuracy.test.ts | ||
| storage-path-resolution.test.ts | ||
| verb-cursor-pagination.test.ts | ||
| vfs-mkdir-bug.test.ts | ||