ADF Storage Event Trigger StartAsync() Fails Due to Event Grid Provisioning Lock in .NET SDK

Question

ADF Storage Event Trigger StartAsync() Fails Due to Event Grid Provisioning Lock in .NET SDK

Rifatul Islam 0

When starting an Azure Data Factory Storage Event Trigger using the .NET SDK, the StartAsync() call may fail with “Resource cannot be updated during provisioning” even after waiting or retrying.

This happens because the trigger depends on an underlying Event Grid subscription. While the Azure Portal shows “Event Subscriptions are updating,” the resource remains locked internally.

The SDK method StartAsync() only waits for ARM-level completion and does not account for backend Event Grid provisioning and also there is no exposed property to check this state

Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-04-07T18:04:32.3466667+00:00

Hello Rifatul Islam,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

2 answers

Your answer

Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-04-07T18:04:32.3466667+00:00

Hello Rifatul Islam,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Answer 1

Praveen Kumar Gudipudi 2,275 Microsoft External Staff Moderator

Hello Rifatul Islam,

Thank you for reaching out regarding the issue with starting the Storage Event Trigger using the .NET SDK.

Summary of the Issue

We understand that when invoking StartAsync() on an Azure Data Factory Storage Event Trigger, the operation intermittently fails with the error:

"Resource cannot be updated during provisioning"

even after incorporating delays or retries.

This behavior is related to the underlying dependency between Azure Data Factory Storage Event Triggers and Azure Event Grid subscriptions.

When a Storage Event Trigger is created or updated:

An associated Event Grid subscription is provisioned asynchronously in the backend.

While the Azure Resource Manager (ARM) operation may complete successfully, the Event Grid subscription can still be in a provisioning state.

During this time, the resource is internally locked, and any subsequent operations such as StartAsync() may fail with:

"Resource cannot be updated during provisioning"

At present, the .NET SDK StartAsync() method only tracks ARM-level completion and does not account for the backend provisioning status of the Event Grid subscription. Additionally, there is no exposed SDK property to validate this provisioning state.

Recommended Approach:

To mitigate this issue, we recommend the following:

Implement Retry Logic with Exponential Backoff

Handle the specific provisioning error and retry the StartAsync() operation after a delay (for example, 15–30 seconds, increasing gradually).

Introduce a Stabilization Delay

After creating or updating the trigger, allow a buffer time (typically 1–2 minutes) before invoking StartAsync().

Ensure Idempotent Operations

Design your implementation so repeated StartAsync() calls do not cause unintended side effects.

Portal Validation (Optional for Testing)

In the Azure Portal, verify whether the Event Subscription shows a status such as “Updating”. Once this completes, the trigger start operation should succeed.

Additional Notes

This is a known behavior due to eventual consistency between ARM and downstream resource providers. While this may appear intermittent, it is dependent on backend provisioning timelines within Event Grid.

Conclusion

The observed failure is not indicative of an issue with your implementation, but rather a timing dependency on Event Grid provisioning. Incorporating retry logic and a short delay before starting the trigger should help ensure consistent success.

This is not a bug in your implementation, but a timing gap between ARM and Event Grid provisioning. Since the SDK does not expose Event Grid readiness, the most reliable approach is retry with backoff + slight delay before starting the trigger.

Please accept as answer and do a Thumbs-up to upvote this response if you are satisfied with the community help. Your upvote will be beneficial for the community users facing similar issues.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Rifatul Islam 0 Reputation points

2026-03-24T17:59:17.55+00:00

Hi Praveen Kumar Gudipudi,
Thank you for replying to my question. I have updated my code and tried your approach, but I am still encountering the same issue.
Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-03-25T10:10:43.81+00:00
Hello Rifatul Islam,

Your implementation correctly:

Adds an initial delay

Implements exponential backoff

Checks RuntimeState before invoking StartAsync()

However, the challenge here is that:

The trigger RuntimeState does not reflect the readiness of the underlying Event Grid subscription.

Even when the trigger shows Stopped, the associated Event Grid subscription may still be internally provisioning or locked, which results in the error:

"Resource cannot be updated during provisioning"

This is due to a timing gap between ARM completion and downstream Event Grid provisioning, and currently:

The .NET SDK does not expose Event Grid provisioning status

StartAsync() does not internally wait for backend readiness

Why Retries Alone Are Not Sufficient

In this scenario, retries on StartAsync() may continue to fail if the backend resource has not yet stabilized. This is not a typical transient failure — it persists until provisioning fully completes.

Recommended Approach

To improve reliability, we recommend introducing a stabilization check before calling StartAsync(), rather than relying solely on runtime state and retries.

Add a Stability Check (ETag-based)

You can poll the trigger resource and ensure that its ETag remains unchanged across consecutive reads, which indicates that backend updates have completed.

Concept:

Fetch trigger metadata repeatedly

Compare ETag values

Proceed only when ETag stabilizes

Update Retry Handling

In addition to BadRequest, we recommend handling broader provisioning-related errors, such as:

"Resource cannot be updated during provisioning"

"Another operation is in progress"

This ensures retries are triggered for all relevant transient provisioning states.

Increase Total Retry Duration

Based on observed behavior:

Event Grid provisioning may take several minutes (up to ~10 minutes in some cases)

Current retry window may not be sufficient

Recommendation:

Increase retry attempts (e.g., 12–15)

Allow longer maximum delay window

Add a Small Buffer Before Start

Even after a successful GET and stability check, adding a short delay (10–15 seconds) before calling StartAsync() can help avoid edge timing issues.
Rifatul Islam 0 Reputation points

2026-03-29T05:54:57.7+00:00

Hi Praveen Kumar Gudipudi,

Thank you for your suggestions.

I have tried all the recommended approaches, including adding a long delay after trigger creation and implementing multiple retries with a delay of more than 3 minutes.

From my observations in the Azure Portal, when I manually start the trigger, the associated Event Grid subscription takes approximately 2–3 minutes to complete provisioning. I can clearly see the provisioning status there.

During execution of my code:

Before calling StartAsync(), I manually verify in the Azure Portal that the Event Grid subscription provisioning state is Completed.

However, once StartAsync() is invoked, the provisioning state changes again to Updating/Creating (depending on whether it’s the first attempt or a retry).

This update process again takes around 2–3 minutes to complete in the backend.

The issue is that StartAsync() does not wait for this backend provisioning to complete. Instead, it throws the error:

"Resource cannot be updated during provisioning"

This happens even though the Event Grid subscription eventually completes successfully after a few minutes.

Because StartAsync() fails before provisioning completes, the trigger does not start. This behavior occurs consistently on every attempt.

So effectively, even when I ensure the Event Grid subscription is in a completed state before calling StartAsync(), invoking StartAsync() itself causes another backend update, and the method fails before that update finishes.

Could you please advise how to handle this scenario, where StartAsync() triggers a backend update and fails before the provisioning process completes?
Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-04-02T15:25:51.65+00:00
Hello Rifatul Islam,

The most reliable pattern currently is to avoid waiting for the LRO inside StartAsync() and instead perform manual polling of the trigger state.

Key Change

Use:

WaitUntil.Completed

instead of:

WaitUntil.Started

or even better, use WaitUntil.Completed with external polling.

Suggested Implementation:

private async Task StartTriggerSafeAsync(string triggerName, PipelineConfig config)

{

var dataFactory = await GetDataFactoryResource(config); var triggerClient = dataFactory.GetDataFactoryTriggers(); var trigger = (await triggerClient.GetAsync(triggerName)).Value; if (trigger.Data.Properties.RuntimeState == DataFactoryTriggerRuntimeState.Started) return; // Fire start operation but don't rely on SDK completion polling await trigger.StartAsync(WaitUntil.Completed); // Manual verification loop for (int i = 0; i < 20; i++) { await Task.Delay(TimeSpan.FromSeconds(30)); var refreshed = (await triggerClient.GetAsync(triggerName)).Value; if (refreshed.Data.Properties.RuntimeState == DataFactoryTriggerRuntimeState.Started) { Logger.Info($"Trigger '{triggerName}' started successfully."); return; } Logger.Info($"Waiting for trigger '{triggerName}' to reach Started state..."); } throw new TimeoutException($"Trigger '{triggerName}' did not reach Started state.");

}

Why This Works Better:

This pattern avoids relying on the SDK's internal polling, which does not account for the Event Grid provisioning lifecycle.

Instead it:

Sends the start request

Lets ADF + Event Grid complete provisioning asynchronously

Polls the actual runtime state of the trigger

This aligns with how the Azure Portal handles trigger activation internally.

Additional Recommendation

If you want maximum reliability in automation pipelines:

Add a post-start verification loop (5–10 minutes max)

Handle these transient errors explicitly:

Resource cannot be updated during provisioning

Another operation is in progress

Operation timed out

Answer 2

The described behavior is expected because starting a Data Factory storage event trigger involves two distinct layers of operations:

An ARM/ADF trigger start operation.
Backend Event Grid event subscription provisioning.

DataFactoryTriggerResource.StartAsync(WaitUntil, CancellationToken) only tracks the long‑running ARM operation for the trigger start (Triggers_Start), not the internal Event Grid subscription provisioning state. ARM can report completion while Event Grid is still provisioning or updating the underlying event subscription, which can leave the trigger in a transient “locked” state where updates fail with messages like “Resource cannot be updated during provisioning.”

Event Grid itself exposes a provisioningState for create/update/delete operations, where only Succeeded, Failed, or Canceled indicate completion; any other value (for example, Accepted) means the operation is still running and the resource may be locked for updates.

For Data Factory triggers, the SDK surface that exposes the event subscription status is separate from StartAsync:

In the newer Azure.ResourceManager.DataFactory SDK:
- DataFactoryTriggerResource.GetEventSubscriptionStatusAsync() returns a DataFactoryTriggerSubscriptionOperationResult that represents the trigger’s event subscription status.
In the older Microsoft.Azure.Management.DataFactory SDK:
- BeginSubscribeToEventsAsync(...) starts subscription to events and returns a TriggerSubscriptionOperationStatus.
- GetEventSubscriptionStatusWithHttpMessagesAsync(...) returns TriggerSubscriptionOperationStatus wrapped in AzureOperationResponse, which can be used to inspect the subscription status.

Because StartAsync does not wait on Event Grid provisioning, robust code should:

Call StartAsync(WaitUntil.Started or Completed) to initiate the trigger start.
Poll the trigger’s event subscription status until it indicates completion, using:
- GetEventSubscriptionStatusAsync() in the Azure.ResourceManager.DataFactory library, or
- GetEventSubscriptionStatusWithHttpMessagesAsync() (or the corresponding convenience method) in Microsoft.Azure.Management.DataFactory.
Only treat the trigger as fully started once the event subscription status indicates that the subscription operation has completed successfully.
If the status indicates the subscription is still being created/updated, implement retry logic with backoff before attempting further StartAsync or other update operations.

This pattern aligns with Event Grid’s general guidance: operations that are still provisioning return a provisioningState other than Succeeded/Failed/Canceled, and update operations can be blocked while that state is in progress. Retrying StartAsync alone without checking the subscription status can work eventually, but polling the event subscription status provides a more deterministic and observable approach.

Additionally, ensure the storage event trigger prerequisites are satisfied so that Event Grid subscription creation can succeed and not remain stuck:

The subscription must be registered with the Microsoft.EventGrid resource provider, and the caller must have Microsoft.EventGrid/eventSubscriptions/* permissions (for example, via the EventGrid EventSubscription Contributor role).
If the storage account is behind a private endpoint or has network restrictions, configure network rules or Event Grid private endpoints so Event Grid can communicate with the storage account.
Be aware that storage event triggers rely on Event Grid and are subject to its limits and behaviors (for example, max 500 storage event triggers per storage account).

In summary, the correct mitigation is to combine StartAsync with explicit polling of the trigger’s event subscription status and to implement retry logic until the Event Grid provisioning has completed, rather than relying on StartAsync alone to represent end‑to‑end readiness.

References:

Share via

ADF Storage Event Trigger StartAsync() Fails Due to Event Grid Provisioning Lock in .NET SDK

2 answers

Your answer