Absorb in flight backup copies superseded by a truncation

[hg-ms]

Problem

When the backup is enabled, a live-file truncation (notably the transactions-log compaction's truncate-and-rewrite) can land while the backup thread is mid-copy of that file. The pre-truncation queue surgery (trimPendingCopyItemsBeyond) only
removes queued copy items — an item the backup thread has already dequeued is invisible to it. That in-flight copy then reads past the new file end, fails the byte-count check, and escalates to a storage-wide disruption — even though the
truncation that shortened the source makes the copied range irrelevant.

Latent since transaction-file housekeeping was introduced; turned from silent backup corruption into a loud fail-stop once copy sites gained byte-count validation.

Fix

StorageBackupItemQueue.processNextItem now inspects the queue when a copy fails: if a truncation discarding the copied range — or a deletion of the whole file — is queued behind the failed item, the failure is absorbed (debug-logged, not
escalated). The trailing items reconcile the backup, so skipping is a no-op. Genuine copy failures, with nothing superseding them, escalate exactly as before.

To make that check sound, StorageFileWriterBackupping enqueues the truncation/deletion marker before the physical op rather than after. Since the physical op is what fails the copy, the marker is guaranteed present when the absorption check
runs — closing the window where the check could miss it and escalate spuriously.

Scope & safety

• Two files: StorageBackupItemQueue, StorageFileWriterBackupping. No API or format change.
• Non-blocking: the absorption scan briefly takes the existing queue monitor and holds no file monitors across it — the queue's leaf-lock discipline is preserved, no new lock ordering.
• A physical op failing after its marker is enqueued only affects a transient crash window; restart resynchronization already rebuilds a diverged backup file.

[Copilot]

Pull request overview

This PR hardens the storage backup pipeline against a race where a live-file truncation (or deletion) occurs while the backup thread is mid-copy, causing a short read and an otherwise avoidable storage-wide disruption.

Changes:

• Reorders backup-queue mutations in StorageFileWriterBackupping so truncation/deletion markers are enqueued before the physical operation (closing the race where the backup thread could miss the superseding marker).
• Extends StorageBackupItemQueue.processNextItem to absorb StorageExceptionBackupCopying failures when the failed in-flight copy is superseded by a pending truncation (discarding that range) or deletion for the same file.
• Updates queue-trimming documentation to clarify that it only affects queued items and that in-flight copies are handled during processing.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
storage/storage/src/main/java/org/eclipse/store/storage/types/StorageFileWriterBackupping.java	Enqueues truncation/deletion markers before physical truncate/delete to ensure superseding items are visible when an in-flight copy fails.
storage/storage/src/main/java/org/eclipse/store/storage/types/StorageBackupItemQueue.java	Adds failure-absorption logic for superseded in-flight copies and documents/implements the pending-superseder scan.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.