Migrate to the New Azure Storage SDKs #763

wsugarman · 2022-07-12T05:48:42Z

Fixes #516

This Pull Request is unfortunately rather long as it required replacing WindowsAzure.Storage with the three new libraries for the Azure Blob, Queue, and Table Storage service client SDKs. These SDKs continue to wrap the REST APIs for each of the respective services, but they rely upon the new primitives leveraged across all of the Azure SDKs for .NET. The changes can be summarized (so far) as follows:

Remove the dependency on WindowsAzure.Storage across the libraries and replace it with:
- Azure.Data.Tables
- Azure.Storage.Blobs
- Azure.Storage.Queues
Replace all of the data models with their replacements including:
- string -> ETag?
- DynamicTableEntity -> TableEntity
- CloudQueueMessage and Durable Task's QueueMessage with the built-in QueueMessage
- CloudTable -> TableClient
- CloudQueue -> QueueClient
- CloudBlob -> BlobClient
Replace the removed TableQuery<T> with raw OData queries
- We could replace them with Expression<T> trees as well, but for performance it probably makes sense to use the OData if it's not too difficult to read and validate
Update the TableEntityConverter to use cached dynamic serialization and deserialization delegates using Expression trees
Replace StorageAccountDetails with StorageAccountClientProvider the encapsulates factories for blob, queue, and table service clients
Replace the TimeoutHandler and some of the AzureStorageClient with a series of HttpPipelinePolicy objects that run throughout the processing of an HTTP request; we rely on the clients own built-in retry as opposed to building our own
Add CancellationToken parameters and update method signatures to use IAsyncEnumerable<T>/AsyncPageable<T> throughout the internal clients; consider adding to the public APIs (for now I added them for APIs that return IAsyncEnumerable<T>)

This reverts commit 0d47a76.

cgillum

Thanks for this PR, Will! I think this would also be a good opportunity for us to bump the version of this package to v2.0.0, since we're changing a major dependency and since we're removing a lot of legacy public APIs.

jviau · 2022-07-13T21:34:01Z

Love to see this change. It is pretty dense though as you said. I do have a question: for consumers that already use these new clients and specifically the dependency injection extensions from Azure SDK, have you included a pattern so that we can just re-use all that configuration and pass an already configured TableServiceClient/BlobServiceClient/QueueServiceClient to DurableTask.AzureStorage?

Reading a bit of the PR, I do have concerns for this as is. Specifically around the dependency on the custom pipeline policies being injected to the all the clients. I understand how you design needs those, but can we explore if there is a good way to allow consumer to use existing clients? I think this is important as the Azure SDK team has already provided a great way to configure and build clients via IConfiguration and dependency injection. It would be nice to see this change embrace that instead of side stepping it. But of course this PR is not where I expect DTFx to bring in DI and IConfiguration - that is a whole other chunk of work. What I am thinking is:

Are the pipeline policies the only way these tasks can be accomplished?
If they are required, can we expose some helpers/APIs consumers can use to apply them to their existing clients?

wsugarman · 2022-07-13T23:45:05Z

Love to see this change. It is pretty dense though as you said. I do have a question: for consumers that already use these new clients and specifically the dependency injection extensions from Azure SDK, have you included a pattern so that we can just re-use all that configuration and pass an already configured TableServiceClient/BlobServiceClient/QueueServiceClient to DurableTask.AzureStorage?

Reading a bit of the PR, I do have concerns for this as is. Specifically around the dependency on the custom pipeline policies being injected to the all the clients. I understand how you design needs those, but can we explore if there is a good way to allow consumer to use existing clients? I think this is important as the Azure SDK team has already provided a great way to configure and build clients via IConfiguration and dependency injection. It would be nice to see this change embrace that instead of side stepping it. But of course this PR is not where I expect DTFx to bring in DI and IConfiguration - that is a whole other chunk of work. What I am thinking is:

Are the pipeline policies the only way these tasks can be accomplished?

If they are required, can we expose some helpers/APIs consumers can use to apply them to their existing clients?

Yes, I have been thinking about this, as we'll ultimately read the client configurations for the Durable Functions extensions from the app settings (similar to how we do it today for Managed Identity and how the Functions Host handles the new client SDKs). I am not yet satisfied with my current draft's solution, so I'll be noodling on that a bit more. I agree that we want to enable users to be able to easily configure their client options and potentially re-use their service clients. There are extensions provided by the Azure extensions SDK to resolve the options and the client from the configuration automatically.

But should we use the policies? I think it's the most desired way of performing these sorts of actions, as we're relying on the native retry capabilities of the SDKs (it may become confusing to allow users to configure retries separately from the client options). However, it is definitely not easy to give users the flexibility of providing their own clients and our own policies. Perhaps DI could indeed help here with something like named options...?

cgillum

First round of comments before I head out on vacation. I'm really excited about this PR! I'm hoping that @davidmrdavid and @amdeel can help push it forward in the meantime!

cgillum · 2022-07-18T23:34:54Z

src/DurableTask.AzureStorage/AzureStorageProvider.cs

+        /// <param name="options">An optional set of client options.</param>
+        /// <returns>An Azure Queue Storage service client whose connection is based on the given <paramref name="accountName"/>.</returns>
+        /// <exception cref="ArgumentNullException">
+        /// <paramref name="accountName"/> is <see langword="null"/> or consists entirely of white space characters.


nit: I think whitespace is one word?

The method string.IsNullOrWhiteSpace uses two words, but I see the wikipedia page uses one. A cursory Google search shows a hyphenated approach with "white-space." I'll let you choose which one we use lol!

src/DurableTask.AzureStorage/DurableTask.AzureStorage.csproj

cgillum · 2022-07-18T23:40:03Z

src/DurableTask.AzureStorage/DurableTask.AzureStorage.csproj

@@ -32,20 +32,24 @@
  </PropertyGroup>

  <ItemGroup>
+    <PackageReference Include="Azure.Core" Version="1.24.0" />
+    <PackageReference Include="Azure.Data.Tables" Version="12.6.0" />


I see that there's already a 12.6.1 version available. Should we make the version numbers here to be {major}.{minor}.* just so that we automatically pick up the patch fixes?

We can definitely do that to make it easier. However, I don't see other package references using the wildcard. Is it ok we do it for these?

cgillum · 2022-07-18T23:43:37Z

src/DurableTask.AzureStorage/DurableTask.AzureStorage.csproj

+    <PackageReference Include="Azure.Core" Version="1.24.0" />
+    <PackageReference Include="Azure.Data.Tables" Version="12.6.0" />
+    <PackageReference Include="Azure.Storage.Blobs" Version="12.12.0" />
+    <PackageReference Include="Azure.Storage.Queues" Version="12.10.0" />


We'll need to be careful about our version selection here since we need to remain compatible with other storage related packages, like Microsoft.Azure.WebJobs.Extensions.Storage. In particular, we'll need to see which versions exist for which extension bundles so that we can know which Azure Functions extension bundles we can safely include this change in. FYI @davidmrdavid

Yes, this is something to be careful with. A good source of reference to quickly validate compatibility with Extension Bundles is to look at the release notes here, which contain the versions of each NuGet package included in a bundles release.

I'm happy to help test more in-depth once other parts of the PR feedback are addressed. For now, I'd say we can keep this in the backburner

Oh ok! I see that Microsoft.Azure.WebJobs.Extensions.Storage.Queues and Microsoft.Azure.WebJobs.Extensions.Storage.Blobs use Azure.Storage.Blobs (>= 12.12.0)
Azure.Storage.Queues (>= 12.10.0). For our purposes, does that mean we can continue to use the latest 12.* version, or should we pin the minimums?

cgillum · 2022-07-18T23:45:10Z

src/DurableTask.AzureStorage/DurableTask.AzureStorage.csproj

    <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.*" PrivateAssets="All" />
+    <PackageReference Include="System.Linq.Async" Version="6.0.1" />


I'm not sure if we'll be able to safely add dependencies to 6.x framework package versions since many of them remove support for .NET Core 2.x (and we still have Azure Functions customers that depend on this older framework). We'll need to do some follow-up research on this.

While it looks like a framework package, it is actually outside of the BCL so it shouldn't conflict with earlier frameworks on its own. However, its dependencies like Microsoft.Bcl.AsyncInterfaces is an out-of-band (OOB) package meant to shim IAsyncEnumerable<T> into .NET Standard (and standard-compatible) frameworks. I don't think there should be an issue using the latest .NET 6-equivalent APIs in a .NET Core 3.1 app, but I'll check.

cgillum · 2022-07-18T23:58:12Z

src/DurableTask.AzureStorage/Http/MonitoringHttpPipelinePolicy.cs

+
+        public override void Process(HttpMessage message, ReadOnlyMemory<HttpPipelinePolicy> pipeline)
+        {
+            stats.StorageRequests.Increment();


I love this pipeline stuff you've added! It seems to nicely cover much of the functionality we had before!

Thanks! Hopefully it makes things a little easier.
I did have to convert the error decoration into an extension method though. I originally also tried to write it as policy, but request failure exceptions are not thrown by the HTTP pipeline. Instead, each client (like the BlobServiceClient) is responsible for interpreting the response codes and throwing exceptions as appropriate. So we must wrap each client's method with the new DecorateFailure method, as we do not want to make assumptions about how each method treats each status code ahead of time.

This reverts commit a44c125.

wsugarman · 2022-10-29T21:56:49Z

src/DurableTask.AzureStorage/Partitioning/BlobPartitionLease.cs

    using System.Threading.Tasks;
    using DurableTask.AzureStorage.Storage;
    using Newtonsoft.Json;

-    class BlobLease : Lease
+    class BlobPartitionLease : Lease


The name BlobLease is used by the blob library, so I thought I'd change these type names to avoid the ambiguity and make their purpose a bit clearer

wsugarman · 2022-10-29T21:57:24Z

src/DurableTask.AzureStorage/SimpleBufferManager.cs


    /// <summary>
    /// Simple buffer manager intended for use with Azure Storage SDK and compression code.
    /// It is not intended to be robust enough for external use.
    /// </summary>
-    class SimpleBufferManager : IBufferManager


This interface no longer exists

jviau

Looking great! Nice to see it narrowed down to just AzureStorage.

Not fully done with the review, but some comments for now.

src/DurableTask.AzureStorage/MessageManager.cs

jviau · 2022-11-02T22:48:28Z

src/DurableTask.AzureStorage/Partitioning/BlobPartitionLeaseManager.cs

-            }
-
-            await Task.WhenAll(downloadTasks);
+                BlobPartitionLease[] leases = await Task.WhenAll(page.Values.Select(b => this.DownloadLeaseBlob(b, cancellationToken)));


I see this is going to do a fan out download, then yield them all one by one. Was this intentionally chosen? If not, what do you think of:

await foreach (Blob blob in this.taskHubContainer.ListBlobsAsync(this.blobDirectoryName, cancellationToken: cancellationToken)) { yield return await this.DownloadLeaseBlob(blob, cancellationToken); }

Yeah, we can definitely do that. I think the only disadvantage is that we'll execute the downloads serially instead of batching them like they are done today on the thread pool. However, given that the max partitioning is 16 (and is usually the default 4), this probably has a minimal performance impact that may be outweighed by its improved readability.

jviau · 2022-11-02T23:00:40Z

src/DurableTask.AzureStorage/Partitioning/Lease.cs

-        public virtual bool IsExpired => false;
+        public virtual Task<bool> IsExpiredAsync(CancellationToken cancellationToken = default)
+        {
+            return Task.FromResult(false);


Tiny nit: tasks have non-negligible GC impact (depending how often this is called). I like to cache constant tasks like this in a readonly static.

I think in this case, the runtime is actually taking care of the cache given that the domain of possible boolean values is small (2). I just read about it here recently when learning about ValueTask:

And since there are only two possible Boolean results (true and false), there are only two possible Task objects needed to represent all possible result values, and so the runtime is able to cache two such objects and simply return a cached Task with a Result of true, avoiding the need to allocate. Only if the operation completes asynchronously does the method then need to allocate a new Task, because it needs to hand back the object to the caller before it knows what the result of the operation will be, and needs to have a unique object into which it can store the result when the operation does complete.

jviau · 2022-11-02T23:01:09Z

src/DurableTask.AzureStorage/Partitioning/LeaseCollectionBalancer.cs

@@ -82,7 +81,7 @@ private static bool DefaultLeaseDecisionDelegate(string leaseId)
        public async Task InitializeAsync()


Is there a cancellation token to forward here? Doing such a good job adding them everywhere else 😄

Ah whoops! Good catch

After looking at it, I think we may want to postpone this as I think I'd need to understand the implications of cancellation for the balancer, as it really only seems to start up and shut down 😅

jviau · 2022-11-02T23:03:53Z

src/DurableTask.AzureStorage/Storage/AsyncPageableAsyncProjection.cs

+    using System.Threading.Tasks;
+    using Azure;
+
+    sealed class AsyncPageableAsyncProjection<TSource, TResult> : AsyncPageable<TResult>


Is this type needed/used? Curious what this does that System.Linq.Async can't?

I didn't see anything for this or the synchronous variant. That is mostly because I am trying to maintain the AsyncPageable<T> API while also performing the projections and System.Linq.Async doesn't know about this Azure-only Pageable API. Although I'm open to suggestions too!

jviau · 2022-11-02T23:17:58Z

src/DurableTask.AzureStorage/Storage/TableQueryResponse.cs

+    using System.Threading.Tasks;
+    using Azure;
+
+    class TableQueryResponse<T> : IAsyncEnumerable<T> where T : notnull


Is this a new or existing metric?

jviau · 2022-11-02T23:27:02Z

src/DurableTask.AzureStorage/Tracking/InstanceStoreBackedTrackingStore.cs

        {
            OrchestrationState state = await this.GetStateAsync(instanceId, executionId: null);
            return state != null ? new InstanceStatus(state) : null;
        }

        /// <inheritdoc />
-        public override async Task<IList<OrchestrationState>> GetStateAsync(string instanceId, bool allExecutions, bool fetchInput = true)
+        public override async IAsyncEnumerable<OrchestrationState> GetStateAsync(string instanceId, bool allExecutions, bool fetchInput = true, [EnumeratorCancellation] CancellationToken cancellationToken = default)


I don't know if this is recommended or not, but I tend to not expose the cancellation token publicly on async IAsyncEnumerable methods. Instead, I split into a public and private method:

public IAsyncEnumerable<T> MethodName(...args) { return MethodNameCore(args); } private async IAsyncEnumerable<T> MethodNameCore(...args, [EnumeratorCancellation] CancellationToken cancellationToken = default) { // actual implementation }

The reasoning is dotnet analyzers has a warning about always forwarding cancellation token. Which gets redundant with System.Linq.Async APIs that take in cancellation and also IAsyncEnumerable.WithCancellation() exists. Just a couple lines down that analyzer would flag and require you to write await this.GetStateAsync(instanceId, false, cancellationToken).FirstOrDefaultAsync(cancellationToken); A bit redundant right? By hiding the cancellation token from the public method, we get rid of the redundancy.

I think that makes perfect sense for conciseness. However, I am also seeing recent BCL additions that include an explicit token parameter, like in the ChannelReader type that was introduced with .NET 6 that defines the method ReadAllAsync. There is also DeserializeAsyncEnumerable in the JsonSerializer class. Although, there are not too many examples of IAsyncEnumerable<T> yet in the BCL.

Those are good points and examples. Would be nice for some official guidance from .NET on this, or if they can somehow make the analyzer smart enough. Anyways - I am fine with whichever way you want to go here.

jviau · 2022-11-02T23:31:09Z

src/DurableTask.AzureStorage/Tracking/ODataCondition.cs

+    /// <summary>
+    /// Represents an OData condition as specified by a filter and a projection.
+    /// </summary>
+    public readonly struct ODataCondition


Do we have access to record structs? Would be a good opportunity here.

We can use record struct if we move the project to use <LangVersion>10.0</LangVersion>. That's no big deal, but in this case I don't think we need the automatic equality comparisons. The nicest thing we could use would be the init keyword, but we would need a shim to use that in .NET Standard and .NET Framework. This is actually possible! I do this in my own personal projects, but unsure if we want to include it here lol

No worries about moving it. I was thinking the with operator for records would be the nicer benefit. But yeah, we can worry about language changes another time.

src/DurableTask.AzureStorage/Tracking/OrchestrationInstanceStatusQueryCondition.cs

jviau · 2022-11-02T23:34:25Z

src/DurableTask.AzureStorage/Tracking/ITrackingStore.cs


        /// <summary>
        /// Get The Orchestration State for the Latest or All Executions
        /// </summary>
        /// <param name="instanceId">Instance Id</param>
        /// <param name="allExecutions">True if states for all executions are to be fetched otherwise only the state for the latest execution of the instance is fetched</param>
        /// <param name="fetchInput">If set, fetch and return the input for the orchestration instance.</param>
-        Task<IList<OrchestrationState>> GetStateAsync(string instanceId, bool allExecutions, bool fetchInput);
+        /// <param name="cancellationToken">The token to monitor for cancellation requests. The default value is <see cref="CancellationToken.None"/>.</param>
+        IAsyncEnumerable<OrchestrationState> GetStateAsync(string instanceId, bool allExecutions, bool fetchInput, CancellationToken cancellationToken = default);


Do the IAsyncEnumerable returning methods have to declare CancellationToken on their public contract? Callers can always use .WithCancellation(). Curious if a precedence has been set by the dotnet runtime or any other core libraries.

As mentioned in the earlier comment, an explicit public cancellation token appears to be the growing pattern in the .NET BCLs and in the Azure libraries.

…ge-sdk

jviau

👍 this looks great! Due to the sheer size and complexity of the changes, I think we should have a preview for the major version rev of DurableTask.AzureStorage and get some testing/feedback on it.

jviau · 2022-11-16T18:33:12Z

src/DurableTask.AzureStorage/Tracking/TableEntityConverter.cs

    /// This class makes heavy use of reflection to build the entity converters.
    /// </summary>
    /// <remarks>
-    /// This class is safe for concurrent usage by multiple threads.
+    /// This class is thread-safe.
    /// </remarks>
    class TableEntityConverter


Hard to tell how correct this improvement is. If it is on par with the existing implementation for correctness and reliability, then I am fine with it. The perf improvements are great to see. However, I do wonder how "correct" it is, as all these types are data contracts, which has additional rules around serialization. For example, does this support IExtensibleDataObject? Although that is not too important. AzureStorage (incorrectly) ignores IExtensibleDataObject all throughout its usage of DurableTask.Core types.

jviau · 2022-11-16T18:42:00Z

src/DurableTask.AzureStorage/Tracking/ODataCondition.cs

+    /// <summary>
+    /// Represents an OData condition as specified by a filter and a projection.
+    /// </summary>
+    public readonly struct ODataCondition


No worries about moving it. I was thinking the with operator for records would be the nicer benefit. But yeah, we can worry about language changes another time.

jviau · 2022-11-16T18:50:34Z

src/DurableTask.AzureStorage/Tracking/InstanceStoreBackedTrackingStore.cs

        {
            OrchestrationState state = await this.GetStateAsync(instanceId, executionId: null);
            return state != null ? new InstanceStatus(state) : null;
        }

        /// <inheritdoc />
-        public override async Task<IList<OrchestrationState>> GetStateAsync(string instanceId, bool allExecutions, bool fetchInput = true)
+        public override async IAsyncEnumerable<OrchestrationState> GetStateAsync(string instanceId, bool allExecutions, bool fetchInput = true, [EnumeratorCancellation] CancellationToken cancellationToken = default)


Those are good points and examples. Would be nice for some official guidance from .NET on this, or if they can somehow make the analyzer smart enough. Anyways - I am fine with whichever way you want to go here.

wsugarman · 2022-11-21T19:52:26Z

@jviau, @cgillum, @davidmrdavid - I have added a <VersionSuffix>preview.1</VersionSuffix> to the AzureStorage project to keep this in prerelease. I just looked at what the Azure client sdks did for their prerelease versions a few years ago, but please let me know if you want to use some other convention for the name or change how it is specified in the build.

jviau · 2022-11-21T20:56:14Z

2.0.0-preview.1 is perfect for the version. Thank you!

@wsugarman can you let us know when you consider this ready for merge? It looks all good to me but wondering if you are still validation or working on any further tweaks.

wsugarman · 2022-11-21T22:42:47Z

2.0.0-preview.1 is perfect for the version. Thank you!

@wsugarman can you let us know when you consider this ready for merge? It looks all good to me but wondering if you are still validation or working on any further tweaks.

I've merged with the latest code in main and have re-run the tests. I think it's good-to-go.

markphillips100 · 2022-12-29T06:27:04Z

I've not used Durable Tasks before but I'd like to give this PR a try if possible as I'm dependent on v12 storage deps in my host (not using Azure Functions). Is the preview going to be available soon?

markphillips100 · 2023-01-05T00:44:35Z

FYI @wsugarman I've been using this PR and the hosting provided by @jviau with package reference modification to make use of it. I only build locally and published packages to a local nuget server to try out some things, namely can it help me with a real world use case of managing the creation of long running azure cloud resources.

I am only using the azure storage for all DT processing and had no problems so far. I asked before but any ETA on a merge as I'd really like to use this?

wsugarman · 2023-01-05T01:04:30Z

FYI @wsugarman I've been using this PR and the hosting provided by @jviau with package reference modification to make use of it. I only build locally and published packages to a local nuget server to try out some things, namely can it help me with a real world use case of managing the creation of long running azure cloud resources.

I am only using the azure storage for all DT processing and had no problems so far. I asked before but any ETA on a merge as I'd really like to use this?

I suspect we will merge this in February. I was discussing with the Durable Task team before the holiday, but there is no firm ETA yet. I'll let the others provide a more authoritative timeline.

markphillips100 · 2023-01-05T01:12:24Z

@wsugarman Thanks for the update. Do you anticipate any further changes?

I think for now I can make do with private feed packages for my own needs and swap over to official in feb (or whenever).

cgillum · 2023-01-22T21:14:37Z

/azp run

azure-pipelines · 2023-01-22T21:14:45Z

EDIT: Run triggered successfully

wsugarman added 14 commits June 30, 2022 11:15

Remove WindowsAzure.Storage

dc01680

Update blob

0b45f04

WIP queue

f6dfb3c

Update blob container

5ce4246

WIP

3d6e021

More refactoring

9299d3e

Timeout policy

0d47a76

Revert "Timeout policy"

3f49813

This reverts commit 0d47a76.

Remove common execution code

d985ae6

WIP

589c392

WIP tracking store

e03e574

Re-compile Az project

25c6584

Merge with main

937fe6b

Nit

fd80bf8

cgillum reviewed Jul 12, 2022

View reviewed changes

cgillum requested a review from amdeel July 13, 2022 21:54

xperiandri mentioned this pull request Jul 14, 2022

Added .editorconfig and forced policies within it #768

Open

cgillum reviewed Jul 18, 2022

View reviewed changes

wsugarman added 10 commits July 23, 2022 14:54

Merge branch 'main' into users/wsugarman/storage-sdk

731e7ad

Refactor connections

6aa691c

Misc packages

ad14424

Update interfaces with cancellation

a44c125

Revert "Update interfaces with cancellation"

0d19c21

This reverts commit a44c125.

Update table-related APIs for service bus

7b59fb4

Finish compiling service bus

55ef60d

Compile non-tests

4b046b7

Rename partitioning

087cc96

WIP tests

117a266

Re-rename

2415476

wsugarman commented Oct 29, 2022

View reviewed changes

Nitpicks

0f3263e

jviau reviewed Nov 2, 2022

View reviewed changes

wsugarman added 3 commits November 13, 2022 14:21

Merge remote-tracking branch 'origin/main' into users/wsugarman/stora…

18d04be

…ge-sdk

Begin addressing more feedback

ac37ef4

nitpick

369bf5a

jviau approved these changes Nov 16, 2022

View reviewed changes

wsugarman added 3 commits November 20, 2022 15:30

Merge with main

7cb5799

Remove BinaryData handling

fb16dc6

Merge with main

443b6da

bhugot mentioned this pull request Nov 23, 2022

Does DFM_ALTERNATIVE_CONNECTION_STRING_* Support Identity connection ? microsoft/DurableFunctionsMonitor#59

Open

wsugarman added 3 commits December 16, 2022 16:27

Merge with main

feb4a6a

nit picks

e7af693

Merge again with main

44c8c10

wsugarman added 2 commits January 14, 2023 07:53

Nits

46c39be

Style changes and removed dead code

3a323a4

wsugarman changed the base branch from main to azure-storage-v12 January 22, 2023 22:14

davidmrdavid merged commit ea8a520 into Azure:azure-storage-v12 Jan 23, 2023

wsugarman mentioned this pull request Feb 5, 2023

Update Azure Storage SDK Azure/azure-functions-durable-extension#2377

Merged

6 tasks

		<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.*" PrivateAssets="All" />
		<PackageReference Include="System.Linq.Async" Version="6.0.1" />

		@@ -82,7 +81,7 @@ private static bool DefaultLeaseDecisionDelegate(string leaseId)
		public async Task InitializeAsync()

Migrate to the New Azure Storage SDKs #763

Migrate to the New Azure Storage SDKs #763

Conversation

wsugarman commented Jul 12, 2022 • edited Loading

cgillum left a comment

Choose a reason for hiding this comment

jviau commented Jul 13, 2022 • edited Loading

wsugarman commented Jul 13, 2022

cgillum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wsugarman Oct 20, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jviau left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wsugarman Nov 13, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wsugarman Nov 13, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jviau left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wsugarman commented Nov 21, 2022

jviau commented Nov 21, 2022 • edited Loading

wsugarman commented Nov 21, 2022

markphillips100 commented Dec 29, 2022

markphillips100 commented Jan 5, 2023

wsugarman commented Jan 5, 2023

markphillips100 commented Jan 5, 2023

cgillum commented Jan 22, 2023

azure-pipelines bot commented Jan 22, 2023 • edited by cgillum Loading

wsugarman commented Jul 12, 2022 •

edited

Loading

jviau commented Jul 13, 2022 •

edited

Loading

wsugarman Oct 20, 2022 •

edited

Loading

jviau left a comment •

edited

Loading

wsugarman Nov 13, 2022 •

edited

Loading

wsugarman Nov 13, 2022 •

edited

Loading

jviau commented Nov 21, 2022 •

edited

Loading

azure-pipelines bot commented Jan 22, 2023 •

edited by cgillum

Loading