-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ArgumentException "The function 'XYZ' doesn't exist" when the functions host recycles #577
Comments
I've just experienced this exact same exception under high-load. **DF 1.7.1 **
@cgillum would using the rewind API be a suitable remediation for this? it feels like it should |
Also had this for an Orchestrator around the same time :
|
@cgillum I am using the latest .net core 2.0 ,still facing the same issue .Kindly help. |
@shiwani please open a new issue since this one is closed. Also, please include more information so that we can properly investigate. |
Clearing azure emulator data solved problem for me,
Please educate me if this is the wrong approach. |
@ParthPurani Perfect, thanks a lot! Worked for me! |
@ParthPurani |
Issue
Given sufficient load on a function app, it's possible that an orchestrator function will fail with the following exception during a host recycle:
This is caused by an incorrect validation check that occurs when the functions host is shutting down. The result is that the orchestration transitions into a Failed state.
This issue is expected to impact all versions of the Durable Functions extension.
Workaround
No known workarounds at this time. Any failed orchestrations will need to be restarted from the beginning.
Technical Details
The problem is that the DurableTaskListener "deregisters" a function when its listener is stopped by the functions runtime. It's possible that an orchestrator function may still be running after the listener has been stopped, in which case the
CallActivityAsync
andCallSubOrchestratorAsync
APIs will throw an exception because the target function is no longer listed.The fix should be to relax this validation so that we don't throw in the case where a function has been "delisted", but rather allow the
CallActivityAsync
orCallSubOrchestratorAsync
call to succeed. This will allow the message to be written to the queue, and once the listeners are startup up again, the function-call message can be picked up.The text was updated successfully, but these errors were encountered: