Fix Cancel Upload sometimes doing nothing (BL-16340)

[andrew-polk]

Cancel's whole job is to set one boolean, _progress.CancelRequested, which the upload polls between stages. The publish screen greys out UPLOAD BOOK the instant the user clicks Cancel, and the only thing that ever brings it back is the uploadCanceled websocket event — which C# sends only if that flag is still true when the upload finishes. So anything that stops the flag being set in time leaves the upload running to completion and the button dead for good, which is exactly what was reported.

Three ways that could happen, all fixed here:

1. The cancel request had to queue behind the very work it was trying to interrupt. libraryPublish/cancel was registered to run on the UI thread and (by default) to take the global api sync lock — both of which a long upload can occupy for minutes (offscreen-browser thumbnailing on the UI thread, then BloomPdfMaker.exe pulling the book and its resources back through Bloom's own server). If the POST was stuck until after the upload's last cancellation check, the flag arrived too late to stop anything. It is now registered (handleOnUiThread: false, requiresSync: false), like the other cancel endpoints (progress/cancel, signLanguage/cancelImportVideo), which exist to set a flag and nothing more.

2. A cancel during the pre-upload handshake was thrown away. The client shows Cancel from the moment the user commits, but two api round trips happen before libraryPublish/upload is posted, and HandleUpload opened by clearing CancelRequested. The flag is now cleared in HandleCheckSubscriptionMatch — the first call of every upload attempt — and HandleUpload declines to start if it is already set. HandleCancel reports the cancellation itself when no upload is running, so the user gets the same feedback in that window.

3. The UI had no way back regardless of what C# decided. isCanceling is now also cleared on uploadSuccessful and on an error in the progress box, so the user can never be left with no working button.

Also:

• A cancel that arrives after the server has committed the upload no longer reports "Upload was cancelled". If a book id came back, the book really is on BloomLibrary, and saying otherwise is a falsehood the user might act on.
• WebProgressAdapter.CancelRequested is backed by a volatile field; it is written and read from different threads with no lock between them.
• Bulk upload shares _progress but has no Cancel of its own, so it now clears the flag too; otherwise a leftover cancel could silently stop it before it started.

Tests

Added EndpointHandlerTests.RequestNotRequiringSync_IsServedWhileAnotherRequestHoldsTheSyncLock, which proves the property fix 1 depends on. Verified it is not falsely passing: flipping the interrupting endpoint to requiresSync: true makes it fail.

Note on verification

The bug itself is a race — the reporter could not reproduce it either — so it was not reproduced deterministically here. The fixes are reasoned from the code paths rather than confirmed against a failing repro. Fix 3 is the one that categorically rules out the reported symptom; fixes 1 and 2 address the causes that the code paths support.

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16340

Devin review

---

This change is 

[andrew-polk]

[Claude Opus 5 (1M context) from Andrew's machine during preflight] Consulted Devin on 2026-08-10, up to commit 2fe96846528ee13012d93b0168c850e03d710df5.

Devin ran four times across this branch's commits and its findings drove three of the five commits here. Each finding has its own thread; this is just the tally.

Acted on and resolved

• An error line could re-enable UPLOAD BOOK while a cancel-pending upload was still running — fixed in 8fdbeb6443.
• A cancel clicked just as an upload finished announced the opposite of what happened — fixed in e17c6e5b54.
• The collision dialog's "change the book id" button changed the book's identity on disk and then uploaded nothing — fixed in e17c6e5b54.
• A cancelled upload that ended in failure released nothing, leaving the button dead — fixed in 2fe9684652.
• A cancel-flag reset depending on the UI never allowing a second attempt — assessed as pre-existing and not made worse; reasoning on its thread.

Open, waiting on the developer (three threads)

• Whether the "already on BloomLibrary" dialog should appear at all after a cancel.
• Two identical "Upload was cancelled" lines in the pre-upload window.
• A cancel that overtakes the start-of-attempt reset, and the related "silent when Idle" trade-off.

These three are interrelated — they are all about what the user should see in the moments before an upload really begins — so they are going back as one decision rather than being patched piecemeal. None is a regression against master.

The bot gauntlet stopped here at its four-cycle cap: each Devin pass was finding issues in code written in the previous pass, which is the point to get a human's eyes on it.

Also seen and not mirrored: nine informational items (low signal). Two of them were acted on anyway — the "quiet" ending that sent no event, and the duplicate-report race now closed by a lock — and the rest were assessed, including confirming that moving the cancel handler off the UI thread is safe because the upload already does the same work from a background thread.

CI (pr-automation) passed on every pushed commit. CodeRabbit is configured on this repo but has auto_review disabled, so it did not run.

[andrew-polk]

[Claude Opus 5 (1M context) from Andrew's machine during preflight] Consulted Devin on 2026-08-10, up to commit 4ac067f509.

Re-review clean — every finding is now resolved, and Devin confirms it. All 4 bugs and all 5 Investigate flags raised across six passes are marked resolved by Devin at this commit; 12 informational items were seen and not mirrored (two of them acted on anyway).

The developer answered the earlier decision report, and both open questions were implemented:

• The collision dialog after a cancel — suppressed. The client drops the "is there an existing copy?" reply if the user cancelled while it was in flight, so no dialog appears over an abandoned attempt and no upload is posted to be declined.
• The first moments of an upload — fixed as one change rather than three patches. The client now waits for C# to acknowledge the attempt before Cancel becomes pressable (visible but disabled until then), which removes the start-of-attempt race by construction rather than narrowing it.

One correction worth recording: I claimed on the duplicate-message thread that suppressing the dialog had removed that problem at the source. It had not — if the collision check comes back clean the client posts the upload immediately, and a later cancel overtakes it because libraryPublish/cancel is lock-free while libraryPublish/upload waits on the UI thread. Devin re-reported it, was right, and 4ac067f509 fixes it properly: both declining paths send the release event without a second message.

CI (pr-automation) passed on every pushed commit. CodeRabbit is configured on this repo but has auto_review disabled, so it did not run.