I have already explained why deleting download history should leave files intact. This account goes deeper: restoring removed rows after persistence fails is different from keeping the next save runnable. The download-history queue needs both responsibilities, with different promises to the caller.
Editing rows and ordering persistence are separate jobs
New transfers, terminal updates and human history removal can overlap. Independent asynchronous saves could allow an older list to finish after a newer one. BrowserHost appends work to a downloadWrites promise tail so persistence has an order rather than several uncoordinated writers.
RememberDownloads selects the current profile rows and makes shallow copies when its queued turn executes. That differs from handing the storage layer an array reference captured at the original call. Both the read point and the execution order matter. This queue orders writes in the current process; it does not supply a multi-process transactional lock or immutable deep snapshots of every possible nested object.
Do not leave a rejected promise as the only queue entrance
A then success callback does not run when its predecessor remains rejected. Keeping that rejected promise as the queue tail can prevent later saves from starting their own work. RememberDownloads catches the failure, records an error message and signals changed state, leaving a handled tail for the next operation.
Handling the rejection does not mean the failed save succeeded. DownloadHistoryError tells the person to inspect the file location; a later successful save clears that status. Nor is this an infinite automatic retry of the original write. A subsequent state-triggered save and verification of the failed write are different events, even when the later write eventually contains the desired current history.
Return the removal failure to the caller anyway
ClearDownloadHistory creates write for the actual removal and persistence, while assigning a separately handled promise to the queue tail. It still awaits write for its caller. The queue remains usable, yet the current request still receives the persistence failure. Catching for queue continuity is not the same as swallowing the operation's error.
Finally signals changed state so restored rows and error text are visible after failure as well as success. Private profiles retain their separate condition that skips persistent history storage. The explanation therefore does not claim every removal commits to the same store. Operation outcome, queue health and profile-specific retention each have their own state.
Restore the removed rows rather than an obsolete whole array
RemoveDownloadHistory keeps only the rows it removes and mutates the current collection. If save fails, it reinserts removed rows not already present under the same ID and profile, then sorts by timestamp. Replacing the whole list with its starting snapshot would lose downloads added during the wait.
The original fixture adds a new progressing row inside the save callback and then throws. The new row, original row and another profile's same-ID row must all remain afterward. That merge contract was introduced in the earlier article; here its role is connected to queue failure handling. I do not count the same implementation as a newly created feature merely because it supports another explanation.
An available queue is not proof that persistence completed
The design avoids letting one failed write stop every later request. A queue accepting new work still does not prove that the final list is on disk. Storage success, readback after restart and error visibility are separate observations. Waiting for outstanding writes during shutdown is another part of that lifecycle.
I reviewed the current functions and counterexample test without newly injecting failure into the original app. The synthetic file-receipt package does not implement this promise queue either. An adaptation must distinguish the failure returned to the current caller from the rejection handled to preserve future progress. The useful contract is continued operation without concealing the failed persistence step.