Open gui28347 opened 1 year ago
Facing same issue . working locally and not working in portal
@gui28347 I got resolved
Please follow the steps mentioned in the below documentation . here
In my case I haven't set the Storage Blob Data Contributor role access .
Same issue here! await client.PurgeAllInstancesAsync
returns the same error for me locally.
Any updates on this? This goes very much against what the document claims when it comes to external events:
If there is no orchestration instance with the specified instance ID, the event message is discarded.
from Handling external events in Durable Functions (Azure Functions)
Looking more into this, I think I tracked it down to this:
private bool CheckStatusBeforeRaiseEvent
=> this.durableTaskOptions.ThrowStatusExceptionsOnRaiseEvent ?? this.durabilityProvider.CheckStatusBeforeRaiseEvent;
Unless you set ThrowStatusExceptionOnRaiseEvent
explicitly, it'll use whatever the durability provider says we should do, which for Azure Storage says you should check here: https://github.com/Azure/azure-functions-durable-extension/blob/d01791972a4b9f439b3e83f8a0e2f3e80a5b1914/src/WebJobs.Extensions.DurableTask/AzureStorageDurabilityProvider.cs#L59
And with that being true
the RaiseEventInternalAsync
will first check if the instance is up and healthy, and throw if not here: https://github.com/Azure/azure-functions-durable-extension/blob/d01791972a4b9f439b3e83f8a0e2f3e80a5b1914/src/WebJobs.Extensions.DurableTask/ContextImplementations/DurableClient.cs#L857
It's throwing InvalidOperationException
but I guess for isolated gRPC gets in a way and ultimately we see RpcException
.
Setting following in hosts.json makes the exception not happen:
{
"version": "2.0",
"extensions": {
"durableTask": {
"throwStatusExceptionsOnRaiseEvent": false
}
}
}
We are facing exaclty the same issue.
@MarcinJuraszek I think you are looking in the wrong repo for the DurableClient
. For dotnet-isolated you need the DurableTaskClient
implementation in the repository where I have posted this issue. (correct me if I'm wrong).
In the previous 'dotnet in process' mode the RaiseEventAsync works like a charm and does the correct thing when a non-existent orchestratorid is used for RaiseEventAsync
.
As stated here (IDurableOrchestrationClient)
ArgumentException
when the instance id does not correspond to a valid orchestration instance.InvalidOperationException
The orchestration instance with the provided instance id is not running. For the dotnet-isolated mode however, the documentation says it does silently eat the event that is raised, but in practice the RpcException
is thrown...
Just verified that "throwStatusExceptionsOnRaiseEvent": false
in the host.json will not throw any exception at all...
Trying to migrate a function running in-process to out-of-process dotnet-isolated 7.
Same code works perfectly in in-process mode. Causing this exception in dotnet-isolated 7 after migrating the required code to run as dotnet-isolatd.
Stack: