fix: stop a cancelled upload from starting the ones behind it

[yash-sangwan]

Fixes the draft issue about POST and OPTIONS calls still going out after a cancel.

What was wrong

Cancelling a folder cancels its files one by one. While that is happening the queue is still full of files that are about to be cancelled too, and the old code refilled the queue after every single cancel. So the free slots went straight to files that were seconds away from being cancelled themselves. Each one started for real, which is the POST and the OPTIONS you saw in the network tab.

Cancelling 3000 files started 1498 uploads that nobody wanted.

Two more things came out of the same bug:

1. Those uploads were started and cancelled so fast that S3 had not replied yet with the upload id. Without that id the cancel could not tell S3 to throw the upload away, so it stayed in the bucket as an incomplete multipart upload. You cannot see these in any file listing but AWS still charges for them.

2. The bigger reason the page froze was not the network at all. Every cancelled file wrote to the upload store on its own, and every write copied the whole list of uploads. With 3000 files that is 3000 copies of a 3000 item list. Measured, it blocked the browser for 9.3 seconds. Now it is one write for the whole batch and the same 3000 files take 9 milliseconds.

How to test this

You need a decent number of files, a few hundred at least. The bug gets more obvious the more files there are.

1. Open the dashboard and open the browser DevTools Network tab.
2. Drag in a folder with a lot of files, or select a lot of files with the New button. A few thousand small text files is what shows it best.
3. Wait until you can see uploads actually running.
4. Cancel it. Either hit the X on the folder card in the operations panel, or cancel the individual files.
5. Watch the Network tab while it cancels.

What you should see now:

• No new POST calls with ?uploads= after you hit cancel, and no OPTIONS calls either. The only new requests should be the aborts for the two or three files that were genuinely uploading at that moment.
• The page stays responsive the whole time. You can scroll, click around, open menus while it cancels. Before this it would lock up for a moment and the longer the file list the longer the lockup.
• Every card in the operations panel goes to cancelled. None of them get stuck showing uploading or queued.

Also worth checking that nothing normal broke:

• Upload a folder and let it finish. It should still appear in the listing when it is done, and the progress bars should still move smoothly while it uploads.
• Start two folders uploading, cancel only the first one. The second one should carry on and keep using all the upload slots, not slow down to one file at a time.
• Try it in both upload modes. Settings has a Multipart and a Signed URL option and both had this bug, signed URL slightly worse.
• Pause and resume a large file, then cancel it, and check it still behaves.

If you have access to the bucket, a nice extra check is aws s3api list-multipart-uploads --bucket <your bucket> after cancelling a big folder. It should come back empty or close to it. Before this fix it would list hundreds of leftover uploads.

What changed

• s3-api/src/utils/uploadManager.ts and signedUrlUploadManager.ts: refilling the queue after a cancel now waits until the caller has finished cancelling, so only work nobody cancelled can start.
• s3-api/src/utils/multipartUploader.ts: if the cancel arrives before S3 hands back the upload id, the upload aborts itself once the id shows up. It also skips opening an upload at all if the cancel got there first.
• frontend/src/features/upload/context/upload-context.tsx and stores/use-upload-store.ts: upload events are collected for a tick and written to the store in one go instead of one write per file.

15 new tests, and all 2039 existing tests still pass.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
opndrive	Ready	Preview	Sep 3, 2026 9:41pm UTC
opndrive-docs	Ready	Preview	Sep 3, 2026 9:41pm UTC

[yash-sangwan]

@Rakesh-46-VR am dicy on this, havn't tested, it will definitely take time