S-Drive 3.6 Documentation

deleteMultiParts

Deletes one or more temporary chunk objects directly from storage — the standalone objects your code creates when it PUTs each chunk's raw bytes to a temporary key during a multipart upload (see copyPartMultiPartUpload).

This only reaches temp chunk objects that exist as their own standalone keys in the bucket. Once a chunk has been registered into the multipart session via copyPartMultiPartUpload, that registration copies the data a second time into the session's own internal bookkeeping — a form that isn't a regular object and can't be listed or deleted by key at all. This method has no effect on that copy. Cancelling the session itself is abortMultiPartUpload's job, not this method's.

How to call this method

global static void deleteMultiParts(List<String> awsChunkLocationList)

global static void deleteMultiParts(List<String> awsChunkLocationList, List<String> versionIdList)

The second overload lets you pass a version Id per key, for version-enabled buckets.

Parameters

Parameter

Type

Required

Description

awsChunkLocationList

List<String>

Yes

The exact temporary chunk keys to delete — fileLocation + "." + (partNumber - 1) for whichever parts your code PUT bytes to. This method doesn't derive these for you; you supply the same keys you (or your client-side code) used when uploading each chunk.

versionIdList

List<String>

No

One version Id per entry in awsChunkLocationList, in the same order, for version-enabled buckets. Pass null, or use the first overload, for non-versioned buckets.

Return value

Returns nothing (void). Throws SDriveException if the storage service reports an error — e.g. a key that doesn't exist.

Before you call this

  • You have to already know the keys. In a live upload, your own chunking loop already has this list as it goes. For a cleanup happening after the fact — the more likely case, since this exists for abandoning a stalled upload — you'd reconstruct it yourself from the WIP record's storage key (fileLocation / Key__c) plus however many parts you believe were sent. Nothing discovers orphaned chunk objects for you.

  • This is separate from, and doesn't overlap with, abortMultiPartUpload. Call both when cleaning up a stalled multipart upload: abortMultiPartUpload for the session and any chunks already registered into it, deleteMultiParts for the standalone temp objects sitting in the bucket. Neither one substitutes for the other.

  • A key that doesn't exist (already cleaned up, or a chunk that was never actually PUT) throws SDriveException — wrap in try/catch if you're cleaning up defensively and aren't certain which chunks made it to storage.

Example

// Reconstruct the temp keys for whichever chunks were sent before the upload stalled
List<String> tempKeys = new List<String>();
for (Integer partNumber = 1; partNumber <= chunksSentSoFar; partNumber++) {
    tempKeys.add(info.fileLocation + '.' + (partNumber - 1));
}

try {
    SDriveTools.deleteMultiParts(tempKeys);
} catch (SDriveException e) {
    System.debug(LoggingLevel.ERROR, 'Failed to delete temp chunk objects: ' + e.getMessage());
}