Skip to content

Design pipeline ownership in multi-level Storage client #7060

Description

@lmazuel

I was reviewing the Storage AIO PR, and found something that concerns me a little:

We have several client:

  • BlobServiceClient
  • BlobClient
  • ContainerClient

From a BlobServiceClient, you can receive a BlobClient using “get_blob_client”. “get_blob_client” will create a BlobClient by sharing the same “pipeline”.

This means this code:

with BlobServiceClient(….) as bsc:
    with bsc.get_bloc_client() as bc:
        # pass

Will call twice the aenter and aexit on the transport. That already could be a problem, but if you do code still like this, that starts to become really unhealthy for you:

with BlobServiceClient(….) as bsc:
    with bsc.get_bloc_client() as bc:
        # pass
    bsc.get_account_information()  # transport closed!

Discussing with @johanste , we don't want reference count to enable scenario like "I create BlobServiceClient, from which I create a ContainerClient, from that I create the BlobServiceClient and it stills work".

Current proposal would be if you create a local client from an upper client, the upper client owns the pipeline (or the transport at least) and you need to close them in the correct order.

Metadata

Metadata

Assignees

Labels

ClientThis issue points to a problem in the data-plane of the library.StorageStorage Service (Queues, Blobs, Files)blocking-releaseBlocks release

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions