Skip to content

Feature/storage/bifrost create session#48940

Draft
browndav-msft wants to merge 79 commits intoAzure:feature/storage/bifrostfrom
browndav-msft:feature/storage/bifrost-createSession
Draft

Feature/storage/bifrost create session#48940
browndav-msft wants to merge 79 commits intoAzure:feature/storage/bifrostfrom
browndav-msft:feature/storage/bifrost-createSession

Conversation

@browndav-msft
Copy link
Copy Markdown
Member

move all commits from bifrost-base/createSession

- downgrade blobserviceversion to 2026_04_06
- change AZURE_LIVE_TEST_SERVICE_VERSION to V2026_04_06 in ci.system.properties in azure-storage-common
- create both sync and async
@github-actions github-actions Bot added the Storage Storage Service (Queues, Blobs, Files) label Apr 26, 2026
Copy link
Copy Markdown
Member

@ibrandes ibrandes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall, this looks really good! i left a couple comments about future refactoring before its beta release that can be addressed later on down the line. i'd also like to do a deeper dive into some of the caching and credential logic before beta release, but right now, i think it's in a good state for the private drop.

: BuilderHelper.buildPipeline(storageSharedKeyCredential, tokenCredential, azureSasCredential, sasToken,
endpoint, retryOptions, coreRetryOptions, logOptions, clientOptions, httpClient, perCallPolicies,
perRetryPolicies, configuration, audience, LOGGER);
perRetryPolicies, configuration, audience, LOGGER, null, null);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also for my own knowledge - why don't we pass in sessionOptions here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sessions are supposed to be container scoped. If we passed sessionOptions to a blob, we wouldn't have any way to set it, so I think we'd have to expose a setter for sessionOptions. But creating a session for a single blob would just be overhead, I think. Unless I'm thinking about this all wrong.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a valid scenario to create a session for a single blob. What if you are doing a very large blob download with many buffered download calls?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. I'll read through this and make the change.

Comment on lines +40 to +56
Mono<StorageSessionCredential> createSessionAsync() {
CreateSessionConfiguration config
= new CreateSessionConfiguration().setAuthenticationType(AuthenticationType.HMAC);

return azureBlobStorage.getContainers()
.createSessionWithResponseAsync(containerName, config, null, null)
.map(this::toCredential);
}

StorageSessionCredential createSessionSync() {
CreateSessionConfiguration config
= new CreateSessionConfiguration().setAuthenticationType(AuthenticationType.HMAC);

Response<CreateSessionResponse> response = azureBlobStorage.getContainers()
.createSessionWithResponse(containerName, config, null, null, Context.NONE);
return toCredential(response);
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

across this whole feature, there are 3 separate API calls. i think it would be worth it to create a small internal sync and async helper somewhere builds the config and maps the response that is shared by BlobSessionClient and container clients. by doing this, we can potentially avoid diverging code paths by having everything in the same place.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ibrandes should I refactor this now or for the beta?

* parameter, while in {@link SessionMode#SINGLE_SPECIFIED_CONTAINER} mode);
* {@link AuthStrategy#USE_BEARER_TOKEN} otherwise.
*/
AuthStrategy analyzeRequest(HttpPipelineCallContext context) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also out of scope for this PR, but a refactoring change we should consider before the beta release:

this method was kind of hard to follow, it would be good to extract request eligibility logic from it. the current logic is deterministic and stateless (mode, method, URL shape, comp, container match), so it can live in a small pure utility (e.g., SessionEligibility)

by doing this, it should be easier to do isolated unit testing on it, and if AUTO behavior ever evolves, it will be easier to update.

Copy link
Copy Markdown
Member Author

@browndav-msft browndav-msft Apr 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. I'll do this for the beta

@ibrandes
Copy link
Copy Markdown
Member

/azp run java - storage - ci

@azure-pipelines
Copy link
Copy Markdown

No pipelines are associated with this pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Storage Storage Service (Queues, Blobs, Files)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants