fix(core): never give out a pending_op id twice

A plain rowid is the largest one plus one, so a trash queued in the same
transaction that dropped the newest op took its id. The drain retires the
op it sent by id, so a rename landing deleted the trash queued over it and
the file stayed on Drive (B137). Schema 37 rebuilds pending_op with
AUTOINCREMENT, keeping every id and index.
This commit is contained in:
nvrl committed 2026-10-03 23:44:12 +02:00
1 parent f6456829fb
commit b3e33a7002
4 files changed
+113 -1

No files matched your search

+20
View File
@@ -12,6 +12,26 @@ Conventions:
---
## B137 — A queued change can be deleted by an older one landing
**Status:** Fixed (unverified).
**Found:** 2026-10-03, by the simulation runs (`sim::run`, profile one-client-lan, seed 9), at the
end check for lost data. A file renamed and then deleted stayed on Drive, and the queue was
empty.
**Where:** the `pending_op` table (`crates/pdfs-core/src/db/migrations.rs`) and `Db::delete_op`
in `crates/pdfs-core/src/db/ops.rs`.
**Cause.** `pending_op.id` was a plain `INTEGER PRIMARY KEY`, so SQLite hands out the largest id
plus one, and an id comes back once the newest row is deleted. Deleting a node drops its queued
ops and queues a trash in one transaction, so the trash could take the id of the rename the drain
was sending. When that rename landed, the drain deleted its row by id, which was now the trash.
**Fix.** Schema 37 rebuilds `pending_op` with `AUTOINCREMENT`, so an id is never given out
again.
**Test:** the unit test `a_dropped_op_id_is_never_given_out_again`.
## B136 — A file renamed while its first upload is on the wire goes back to its old name
**Status:** Fixed (unverified).
+7
View File
@@ -11,6 +11,13 @@ scratch (user data in `staging/` and `recovery/` is never touched by this).
## [Unreleased]
Schema: **37**. The queue table is rebuilt so an id is never given out twice; queued changes
are kept.
### Fixed
- **A delete queued while a rename is sent is no longer lost.** The rename landing could remove
the delete from the queue, leaving the file on Drive (B137).
## [2.10.0] — 2026-10-03
Schema: **36**. Every node row gets a local id that never changes; existing rows keep their