Azure Blob SDK 12.30: Block IDs, Resume and Download Memory

Azure Blob SDK 12.30 changes two assumptions worth auditing before an upgrade. In Azure.Storage.Blobs 12.30.0, SDK-generated partitioned-upload block IDs are opaque, and parallel DownloadToAsync buffering can change your process memory profile. Keep resumable-upload order in application-owned state, coordinate competing commits explicitly, and measure transfer settings under your workload.

Our Windows comparison of 12.29.2 and 12.30.0 passed 84 checks and two cross-version gates against Azurite 3.37.0. It checked block IDs, resumed staging, commit order, stale ETags and six downloads of the same 64 MiB blob. The memory measurements below are local observations.

Audit the Azure Blob SDK 12.30 upgrade contracts

The pinned 12.30.0 changelog describes random block IDs for partitioned uploads and concurrent in-memory buffering of download ranges. The stable release includes the changes introduced in its beta versions.

Search application code for block-ID decoding, sorting or reconstruction. A normal UploadAsync call already lets the SDK manage its own block sequence; a custom resume feature needs its own contract. Separately, review parallel download settings and the number of downloads a process can run together.

Observe SDK-generated block IDs

The demo uploads the same 8 MiB payload twice to the same blob, forcing eight 1 MiB blocks. It retrieves each committed list and checks the downloaded SHA-256 after both uploads.

SDK	Blocks per upload	IDs shared between the two uploads	Content checks
12.29.2	8	8	Both SHA-256 values match
12.30.0	8	0	Both SHA-256 values match

Repeated uploads: eight shared IDs with 12.29.2 and zero with 12.30.0, while file contents remain intact.

Two disjoint lists confirm the behavior in this sample. They are not a statistical randomness or collision-resistance test. The useful application rule is simpler: preserve an explicit sequence when you own the upload, rather than inferring byte order from an ID’s spelling.

Own the resume manifest and commit order

The custom-resume example creates six application-owned IDs of equal encoded length, scoped to one upload session. It saves the source SHA-256, block size and ordered ID list before staging. This excerpt uses the demo’s UploadManifest record and Hash helper; the full definitions are in the runnable source:

string session = Guid.NewGuid().ToString("N");
var manifest = new UploadManifest(session, Hash(resumable), MiB,
    Enumerable.Range(0, 6).Select(i =>
        Convert.ToBase64String(Encoding.ASCII.GetBytes($"{session}:{i:D8}")))
        .ToArray());
await File.WriteAllTextAsync(manifestPath,
    JsonSerializer.Serialize(manifest, Json), token);

The proof stages two blocks, reloads the manifest, rejects a changed source, and checks that rejection left the staged list unchanged. Resuming the original source reuses those two blocks and stages the remaining four. The final commit passes the saved sequence directly:

await resume.CommitBlockListAsync(loaded.OrderedBlockIds, cancellationToken: token);

The Put Block List contract uses the supplied block order. Our negative check reverses that order and observes different file bytes; restoring the manifest order restores the original SHA-256. Sorting IDs is not a repair strategy.

This deliberately small example uses a trusted local manifest, equal-sized blocks and an in-memory source. It reloads state within the test process. It does not implement a complete durable upload service or prove recovery after a machine crash.

Guard the final commit with an ETag

Different block IDs do not grant two writers ownership of the same final blob. The test captures the existing blob ETag, stages distinct writer blocks and applies that ETag to both final commit attempts:

var conditional = new CommitBlockListOptions
{
    Conditions = new BlobRequestConditions { IfMatch = originalEtag }
};
await guarded.CommitBlockListAsync([writerA], conditional, token);
// The subsequent writerB attempt uses the same, now-stale ETag.

Writer A succeeds. Writer B is rejected with HTTP 412, and the winner’s contents remain intact. This demonstrates the optimistic concurrency contract through serialized commit attempts; it is not a concurrent-writer load test. An application must resolve a conflict deliberately instead of retrying an unconditional overwrite.

Resume and commit checks: saved order preserves bytes, changed source is rejected, and a stale ETag cannot replace the winning writer.

Measure DownloadToAsync memory

Each profile downloads the same 64 MiB blob in a fresh process. The demo sets the initial and maximum transfer sizes explicitly with the helper below:

private static StorageTransferOptions Transfer(int concurrency, int size) => new()
    {
        MaximumConcurrency = concurrency,
        MaximumTransferSize = size,
        InitialTransferSize = size
    };

MaximumTransferSize is the property used by the tested code. The release note uses MaximumTransferLength; the source exposes that name as a compatibility facade. Transfer options control an individual operation, not the whole process or all simultaneous downloads.

The table shows the sampled peak minus the baseline for managed memory and working set, in MiB. Measurements were taken on Windows with .NET Runtime 10.0.12, using local Azurite and a 10 ms sampling interval.

SDK	Profile	Concurrency	Range MiB	Managed Δ MiB	Working set Δ MiB
12.29.2	low	1	1	1.7	4.1
12.29.2	balanced	4	4	1.1	3.9
12.29.2	wide	8	8	1.1	2.4
12.30.0	low	1	1	1.7	3.8
12.30.0	balanced	4	4	16.8	17.7
12.30.0	wide	8	8	57.5	59.4

All six downloaded files had the same SHA-256. In this run, the newer SDK’s balanced and wide profiles used substantially more sampled memory. This supports measuring the upgrade’s memory tradeoff; it does not establish a production throughput improvement or an SDK-only allocation count.

Local DownloadToAsync measurements across three profiles and two SDK versions. Wider concurrent ranges can increase observed memory.

MaximumConcurrency × range size estimates a range window, not a hard process-memory ceiling. Runtime state, HTTP buffers, the destination, sampling gaps and overlapping operations matter. The sampler may miss a short peak. Start with a conservative profile and tune it under realistic latency, file sizes and application concurrency.

Run the proof

The package needs Node.js 22 or later and the .NET 10 SDK and runtime (a newer compatible SDK can build the net10.0 projects). Both SDK packages and Azurite are pinned. From the extracted demo directory:

Unblock-File .\Verify-Blob.ps1
powershell -NoProfile -ExecutionPolicy Bypass -File .\Verify-Blob.ps1

The runner starts Azurite on 127.0.0.1:10080 with telemetry disabled, records each receipt and writes artifacts/latest/report.html. Both clients explicitly use service API 2023-11-03. This isolates the SDK comparison from emulator support for the newest service APIs; it does not test the new service features in 12.30.0.

Apply the production boundaries

Keep source identity and commit order durable when building resumable uploads. Validate the manifest and source before staging more bytes, and add a clear conflict policy for the final commit. Test ambiguous network failures and recovery separately; those cases exceed this local proof.

For downloads, monitor working set and concurrent operations in the real application. A passing checksum and a larger buffer are different facts. Retest against Azure before choosing production transfer settings from emulator timings.