fix: queue cover thumbnail refresh after metadata commit#1334
Conversation
Saving metadata with a fetched cover queued thumbnail clear/regeneration immediately after the cover file was downloaded, before the edit request had finished applying metadata and committing the Calibre DB transaction. In the live container, the app wedged after queuing those thumbnail tasks and before logging the edit commit. Defer thumbnail cache replacement until after the metadata transaction commits, so background thumbnail work cannot race the active edit session. Add per-stage debug timings around the edit-save path so future stalls identify the exact metadata step that stopped progressing.
|
Same race condition is fixed in the community-maintained CWA build at Thanks @I-Would-Like-To-Report-A-Bug-Please for the independent diagnosis and the static-pin test — both threads landed on the same defer-until-after-commit fix. If you've seen the web UI wedge after saving metadata with a fetched cover, the fix is at |
|
Np @new-usemame, if it helps I am runnning my own docker image, with this, and few other PR patches I’ve submitted recently. |
Saving metadata with a fetched cover queued thumbnail clear/regeneration immediately after the cover file was downloaded, before the edit request had finished applying metadata and committing the Calibre DB transaction. In the live container, the app wedged after queuing those thumbnail tasks and before logging the edit commit.
Defer thumbnail cache replacement until after the metadata transaction commits, so background thumbnail work cannot race the active edit session. Add per-stage debug timings around the edit-save path so future stalls identify the exact metadata step that stopped progressing.