fix(core,fuse): a deleted file's trash is not held back by its create (B171)

A file deleted after its create was sent keeps the op as a trash. The op
kept the create's attempts and backoff, and the drain recorded the failure
of a create attempt still on the wire on the row that was by then the trash.
The trash waited out the create's backoff.

The trash starts due, as a create that becomes a revision does, and the
drain records a failed attempt only if the op is still the kind it ran as
(`Db::record_attempt_failure`).

docs/BUGS.md

@@ -12,6 +12,31 @@ Conventions:
 
 ---
 
+## B171 — A file deleted while its upload fails stays on Drive for the upload's backoff
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by the simulation suite (`one_client_on_a_good_link`, seed 9). The queue
+did not drain within 4 s of the settle: it still held a trash of `b.txt` with one attempt and
+the error "No such file or directory (os error 2)", due seconds later.
+
+**Where:** `drop_doomed_ops` and `Db::record_op_failure` in `crates/pdfs-core/src/db/ops.rs`, and
+the drain loop in `crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** A file deleted after its create was sent keeps its op as a trash, in case the create
+made the node and only its answer was lost (B151). The op kept the create's attempts, error and
+backoff. The drain also recorded the failure of a create attempt still on the wire on the row,
+which by then was the trash. Here the attempt failed because a write had replaced the blob it
+was reading, and the trash waited out the create's backoff.
+
+**Fix.** The trash starts with no attempts and is due at once, as a create that becomes a
+revision already does. The drain records a failed attempt only if the op is still the kind it
+ran as (`Db::record_attempt_failure`).
+
+**Test:** `a_create_deleted_after_it_was_sent_leaves_a_trash_that_is_due_at_once` in
+`crates/pdfs-core/src/db/tests.rs`.
+
+---
+
 ## B170 — A write opened as an upload lands fails the next write with `EIO`
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -70,6 +70,8 @@ by its local id, in the queue, the stored tree and pins alike.
   progress finish, and the rest waits for the next start (B169).
 - **Writing to a file again just as its upload finishes no longer fails.** A write right after
   it failed with "Input/output error" (B170).
+- **A file deleted while its upload was retrying is removed from Drive right away.** It no
+  longer waits for the upload's next retry (B171).
 - **A file renamed just as its upload finished keeps its new name.** The mount no longer showed
   the old name, and a second rename no longer failed with "No such file or directory" (B152).
 - **A change that waits for a name to be freed no longer waits seconds after it is.** A rename or

docs/MILESTONE-3.0.0-STATUS.md

@@ -9,7 +9,7 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
 - **Phase 2**: local ids, inode = local id, one tree for every mount (2.10.0).
 - **Phase 3, first part**: mkdir, create, rename, unlink and rmdir on the mount are recorded
   locally and sent from the queue; `"local_first": false` brings back the old path (5e0f30c).
-- Fixes from the simulation and account runs since then: B127 and B141 to B170.
+- Fixes from the simulation and account runs since then: B127 and B141 to B171.
 - **Sync issues, first cut** (§6.2): refusals sorted into issues, shown at once in the app,
   tray and CLI; Export button and `pdfs sync export`; `pdfs sync issues`.
 
@@ -112,7 +112,9 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          sent again, to the root (B168, fixed), and a stop that let a mirror pass go on
          until the runtime ended under it (B169, fixed). CI on 9bbc994 failed
          `one_client_on_a_good_link`: a write opened as an upload landed took the revision
-         it replaced as its base, and the next write failed with `EIO` (B170, fixed).
+         it replaced as its base, and the next write failed with `EIO` (B170, fixed). The
+         suite's seed 9 found a deleted file's trash waiting out its create's backoff (B171,
+         fixed).
 5. **Release**: 2.10.0 is tagged; the 2.9.0 tag still waits for the user's go-ahead.
 
 ## After 3.0.0