azblob UploadBuffer AccessConditions silently dropped for files over 256 MiB

[embiem]

Bug Report

• import path of package in question: github.com/Azure/azure-sdk-for-go/sdk/storage/azblob (and .../azblob/blockblob)
• SDK version: github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.4.1
  • commit: 47b7a8a545174788f2bc750fdebda9bf4eb1e0ae (tag sdk/storage/azblob/v1.4.1)
  • also reproducible on main (see pointers below)
• output of go version: go version go1.26.0 linux/amd64

What happened?

Client.UploadBuffer / Client.UploadFile accept an AccessConditions field via UploadBufferOptions / UploadFileOptions, but those access conditions are silently dropped when the payload exceeds MaxUploadBlobBytes (256 MiB) and the upload is performed as staged Put Block calls followed by a Put Block List commit.

As a result, a conditional create (IfNoneMatch: "*") is honored for payloads ≤ 256 MiB but not for payloads > 256 MiB — the existing blob is overwritten instead of the request failing.

Root cause is an asymmetry in blockblob/models.go. The single-shot path forwards AccessConditions, but the multi-block commit path used by UploadBuffer/UploadFile does not:

• The size branch in uploadFromReader: ≤ MaxUploadBlobBytes → one Upload (Put Blob); otherwise stage blocks + CommitBlockList:
  

  azure-sdk-for-go/sdk/storage/azblob/blockblob/client.go

  Line 442 in 47b7a8a

  if actualSize <= MaxUploadBlobBytes {

  
  

  azure-sdk-for-go/sdk/storage/azblob/blockblob/client.go

  Lines 520 to 521 in 47b7a8a

  	commitBlockListOptions := o.getCommitBlockListOptions()
  	resp, err := bb.CommitBlockList(ctx, blockIDList, commitBlockListOptions)

• MaxUploadBlobBytes (256 MiB threshold):
  

  azure-sdk-for-go/sdk/storage/azblob/blockblob/constants.go

  Lines 17 to 18 in 47b7a8a

  	// MaxUploadBlobBytes indicates the maximum number of bytes that can be sent in a call to Upload.
  	MaxUploadBlobBytes = 256 * 1024 * 1024 // 256MB

• Single-shot options do carry AccessConditions (so the condition works ≤ 256 MiB):
  

  azure-sdk-for-go/sdk/storage/azblob/blockblob/models.go

  Lines 292 to 302 in 47b7a8a

  	func (o *uploadFromReaderOptions) getUploadBlockBlobOptions() *UploadOptions {
  	return &UploadOptions{
  	Tags: o.Tags,
  	Metadata: o.Metadata,
  	Tier: o.AccessTier,
  	HTTPHeaders: o.HTTPHeaders,
  	AccessConditions: o.AccessConditions,
  	CPKInfo: o.CPKInfo,
  	CPKScopeInfo: o.CPKScopeInfo,
  	}
  	}

• The bug — uploadFromReaderOptions.getCommitBlockListOptions() builds CommitBlockListOptions with no AccessConditions field, so the entire AccessConditions (both ModifiedAccessConditions and LeaseAccessConditions) is discarded on the commit:
  

  azure-sdk-for-go/sdk/storage/azblob/blockblob/models.go

  Lines 304 to 313 in 47b7a8a

  	func (o *uploadFromReaderOptions) getCommitBlockListOptions() *CommitBlockListOptions {
  	return &CommitBlockListOptions{
  	Tags: o.Tags,
  	Metadata: o.Metadata,
  	Tier: o.AccessTier,
  	HTTPHeaders: o.HTTPHeaders,
  	CPKInfo: o.CPKInfo,
  	CPKScopeInfo: o.CPKScopeInfo,
  	}
  	}

• For contrast, the sibling UploadStreamOptions.getCommitBlockListOptions() does forward AccessConditions:
  

  azure-sdk-for-go/sdk/storage/azblob/blockblob/models.go

  Lines 361 to 375 in 47b7a8a

  	func (u *UploadStreamOptions) getCommitBlockListOptions() *CommitBlockListOptions {
  	if u == nil {
  	return nil
  	}
  	return &CommitBlockListOptions{
  	Tags: u.Tags,
  	Metadata: u.Metadata,
  	Tier: u.AccessTier,
  	HTTPHeaders: u.HTTPHeaders,
  	CPKInfo: u.CPKInfo,
  	CPKScopeInfo: u.CPKScopeInfo,
  	AccessConditions: u.AccessConditions,
  	}
  	}

Still present on main: https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/storage/azblob/blockblob/models.go (uploadFromReaderOptions.getCommitBlockListOptions() still omits AccessConditions).

This is purely an SDK omission, not a service limitation — Put Block List supports conditional headers: https://learn.microsoft.com/en-us/rest/api/storageservices/put-block-list ("This operation also supports the use of conditional headers to commit the block list only if a specified condition is met.").

What did you expect or want to happen?

AccessConditions supplied to UploadBuffer/UploadFile should be applied to the final Put Block List commit — exactly as they already are for the single-shot Put Blob path and for UploadStream. With IfNoneMatch: "*", the second upload of an existing blob should fail (409 BlobAlreadyExists / 412 ConditionNotMet) and leave the blob unchanged, regardless of payload size. Either fix it, or document that high-level buffer/file uploads ignore access conditions above MaxUploadBlobBytes.

How can we reproduce it?

Upload the same blob twice with IfNoneMatch: "*". With a payload just over 256 MiB the second call succeeds and overwrites; with a payload ≤ 256 MiB it correctly fails.

package main

import (
    "bytes"
    "context"
    "fmt"

    "github.com/Azure/azure-sdk-for-go/sdk/azcore"
    "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
    "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob"
    "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/bloberror"
)

func main() {
    ctx := context.Background()
    cred, _ := azblob.NewSharedKeyCredential("<account>", "<key>")
    client, _ := azblob.NewClientWithSharedKeyCredential(
        "https://<account>.blob.core.windows.net", cred, nil)

    const container, name = "<container>", "conditional-create-test"

    star := azcore.ETagAny
    opts := &azblob.UploadBufferOptions{
        AccessConditions: &blob.AccessConditions{
            ModifiedAccessConditions: &blob.ModifiedAccessConditions{IfNoneMatch: &star},
        },
    }

    // 260 MiB -> exceeds MaxUploadBlobBytes -> staged Put Block + Put Block List.
    // Change to e.g. 1<<20 (1 MiB) and the second call correctly returns BlobAlreadyExists.
    payload := bytes.Repeat([]byte{'A'}, 260*1024*1024)

    _, err := client.UploadBuffer(ctx, container, name, payload, opts)
    fmt.Println("first :", err) // <nil> (created)

    _, err = client.UploadBuffer(ctx, container, name, payload, opts)
    fmt.Println("second:", err,
        "BlobAlreadyExists:", bloberror.HasCode(err, bloberror.BlobAlreadyExists))
    // EXPECTED: err = 409 BlobAlreadyExists / 412 ConditionNotMet (blob NOT overwritten)
    // ACTUAL  : err = <nil>, the >256 MiB blob is silently overwritten
}

Observed with a small (8 MiB, single-shot) vs. large (260 MiB, multi-block) payload, each uploaded twice with a flipped content marker and overwrite confirmed via GetProperties (ETag) + a ranged read of the live content.

Anything we should know about your environment?

• Linux, go1.26.0, Shared Key credential, standard azblob.Client.
• Threshold is blockblob.MaxUploadBlobBytes (256 MiB): payloads at or below it take the single-shot Put Blob path (condition honored); above it take the multi-block Put Block + Put Block List path (condition dropped).

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

//cc: xgithubtriage

[github-actions]

🎯 Agentic Issue Triage

Summary: AccessConditions supplied to UploadBuffer/UploadFile are silently dropped when the payload exceeds 256 MiB (the MaxUploadBlobBytes threshold), because uploadFromReaderOptions.getCommitBlockListOptions() does not forward AccessConditions to the final Put Block List call — unlike the single-shot Put Blob path and UploadStream, which both correctly propagate them.

📋 Issue Details

Module: github.com/Azure/azure-sdk-for-go/sdk/storage/azblob (and sdk/storage/azblob/blockblob)
Affected API: Client.UploadBuffer, Client.UploadFile, uploadFromReaderOptions.getCommitBlockListOptions()
Scenarios:

• Upload with IfNoneMatch: "*" on a payload ≤ 256 MiB: condition is honored — second upload correctly fails with 409 BlobAlreadyExists / 412 ConditionNotMet
• Upload with IfNoneMatch: "*" on a payload > 256 MiB: condition is silently dropped — the existing blob is overwritten instead of failing

Root ask: Fix getCommitBlockListOptions() on uploadFromReaderOptions to propagate AccessConditions to the CommitBlockList call, matching the behavior of UploadStreamOptions.getCommitBlockListOptions() (which already does this correctly). Alternatively, document that high-level buffer/file uploads ignore access conditions above MaxUploadBlobBytes.

🔎 Debugging / Reproduction Notes

The bug is in blockblob/models.go: uploadFromReaderOptions.getCommitBlockListOptions() builds CommitBlockListOptions without setting the AccessConditions field.

The fix is to mirror what UploadStreamOptions.getCommitBlockListOptions() does at models.go#L361-L375 — add AccessConditions: o.AccessConditions to the returned CommitBlockListOptions. The Put Block List REST API supports conditional headers, so there is no service-side limitation.

Suggested investigation steps:

1. Review uploadFromReaderOptions.getCommitBlockListOptions() in sdk/storage/azblob/blockblob/models.go and add AccessConditions: o.AccessConditions to the returned struct.
2. Verify the fix using the minimal repro in the issue (260 MiB payload, IfNoneMatch: "*", second upload should return 409/412).
3. Add a unit/live test covering the > MaxUploadBlobBytes path with AccessConditions set.

🏷️ Label Confidence

• Category: Client — This is a data-plane SDK bug in sdk/storage/azblob; the service REST API itself supports conditional headers correctly.
• Service: Storage — Module path is sdk/storage/azblob.
• Confidence: High — Module path is explicit, the bug is clearly in SDK client code (not ARM/resource manager), and this matches the pattern of reference issue ContentMd5 contains invalid UTF-8 #19206 (Client + Storage for azblob bugs).

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Storage (line 127) — matched on Storage label; this is the last %Storage entry in the file and thus the first encountered in bottom-to-top scanning.
• AzureSdkOwners: none listed in this entry
• ServiceOwners: @xgithubtriage
• Routing action: Added "Service Attention" and "needs-team-attention" labels; mentioned @xgithubtriage via routing comment.
• Scan notes: An earlier entry (line 124) also matches %Storage and lists AzureSdkOwners: Joel Hendrix (@jhendrixMSFT) / `ServiceOwners: `@tanyasethi-msft, but it is higher in the file and therefore skipped in favor of the lower entry (line 127) per bottom-to-top first-match-wins semantics.

Generated by Agentic Triage for issue #27031 · ● 308.6K · ◷