del, which deletes one path, a list of paths, or everything under a prefix, and the calls that clean up multipart uploads that were never completed.
Promise<void> and treat “already gone” as success. They differ in how many requests they make and what they throw when storage refuses part of the work.
invalid_input. A path with a . or .. segment throws a TypeError; see Paths.
The upload handler also deletes on its own: a throw out of onUploadComplete, or a cancel() from the browser, removes the object that upload wrote. See onUploadComplete.
One path
DELETE request. A 404 counts as success, so a delete is safe to run from a retried job or an at-least-once queue consumer. Any other failure throws; see Errors.
del never says whether anything was there. To find out, call bucket.exists(path) first.
An array
del throws partial_delete with them in failed. Everything not in failed was deleted. To recover, retry with e.failed.
Use BlobError.is(e), never instanceof. See Errors.
A prefix
list() at 1000 objects per page and batch-deletes each page as it goes. A prefix with 100,000 objects is 100 list requests and 100 batch deletes, run one after another. It is not atomic; objects written under the prefix while it runs may or may not be caught.
Failures work as for an array. Survivors from every page are collected and thrown as partial_delete.
move leaves a copy on failure
move is a copy followed by a delete, because storage has no rename. If the copy fails, nothing changed and you get the copy’s error. If the copy succeeds and the delete fails, move throws move_left_a_copy and keeps the destination, so you have two objects rather than none. The original error is on cause.
Incomplete multipart uploads
A multipart upload becomes an object only when it is completed. Until then its parts are billed storage thatlist() cannot see, and the bucket cannot be deleted while one exists. A browser tab closed mid-upload leaves exactly this behind.
bucket.put() and a browser cancel() abort their own uploads on failure. Anything else needs a sweep. The cron that runs it is on Abandoned uploads; the calls it uses are below.
listMultipartUploads
prefix is optional.
abortMultipartUpload
uploadId is refused with invalid_input.
onUploadComplete receives multipartUploadId for exactly this pair. Store it with your row and you can abort a specific upload later without listing the bucket. It is undefined for a single PUT.
abortStaleMultipartUploads
olderThan is required, a Duration. Only uploads started longer ago than that are touched, so a window longer than your slowest upload never aborts one still running. A day is a reasonable default.
An abandoned upload under the multipart threshold is not a multipart upload. It is an ordinary stored object that
list() can see, and none of the calls above can find it. See Abandoned uploads.Error codes
del never raises not_found. Statuses and extra fields are on Errors.