Atomic .docx writes, fix .lily race, lint cleanup #62

Merged
parkerhdavis merged 2 commits from bug-reliability-scan into main 2026-05-21 11:11:18 -06:00
parkerhdavis commented 2026-05-21 10:52:20 -06:00 (Migrated from github.com)

Summary

  • Atomic .docx writes — all seven fs::write sites in docx_ops.rs now route through a new lily_file::atomic_write_bytes, so a crash mid-save can no longer leave a user's document truncated. .lily, settings, and questionnaire writes already had this guarantee; .docx did not.
  • Fix .lily double-read race in new_version_document — the function was reading the .lily file, copying the source document, then dropping and re-reading the .lily. Tauri commands run on a thread pool, so a concurrent writer between those two reads would have its changes silently clobbered. Mutate the value from the first read instead.
  • Lint cleanup — biome make lint now exits clean (was failing on cargo build artifacts because "!target" didn't match nested target dirs). Removed 25 stale biome-ignore comments (suppressing rules already disabled in config), a chain of dead onReloadLilyFile/reloadLilyFile plumbing through ClientsHub.tsx, an unused clientValue prop on LinkedVariableField, several other dead locals/imports/destructures, and a useless try/catch wrapper.

Test plan

  • make check
  • make typecheck
  • make lint (now exits 0)
  • make test — 93/93 passing
  • Manual: create a new client doc, change variables, save — confirm .docx saves cleanly
  • Manual: invoke "New Version" on an existing doc, confirm new dated copy appears and .lily records it
## Summary - **Atomic `.docx` writes** — all seven `fs::write` sites in `docx_ops.rs` now route through a new `lily_file::atomic_write_bytes`, so a crash mid-save can no longer leave a user's document truncated. `.lily`, settings, and questionnaire writes already had this guarantee; `.docx` did not. - **Fix `.lily` double-read race in `new_version_document`** — the function was reading the `.lily` file, copying the source document, then dropping and re-reading the `.lily`. Tauri commands run on a thread pool, so a concurrent writer between those two reads would have its changes silently clobbered. Mutate the value from the first read instead. - **Lint cleanup** — biome `make lint` now exits clean (was failing on cargo build artifacts because `"!target"` didn't match nested target dirs). Removed 25 stale `biome-ignore` comments (suppressing rules already disabled in config), a chain of dead `onReloadLilyFile`/`reloadLilyFile` plumbing through `ClientsHub.tsx`, an unused `clientValue` prop on `LinkedVariableField`, several other dead locals/imports/destructures, and a useless try/catch wrapper. ## Test plan - [x] `make check` - [x] `make typecheck` - [x] `make lint` (now exits 0) - [x] `make test` — 93/93 passing - [ ] Manual: create a new client doc, change variables, save — confirm `.docx` saves cleanly - [ ] Manual: invoke "New Version" on an existing doc, confirm new dated copy appears and `.lily` records it
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
parker/lily!62
No description provided.