-
Notifications
You must be signed in to change notification settings - Fork 54
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
Wait-DurableTask broken in Powershell 7.2 functions #851
Comments
Thanks for the heads up @Ruankr. I'll keep this thread updated on what happened - I'm putting this as a top priority item. |
I noticed there's been a merge to revert the breaking change, but unsure as to how to target this change? At the moment I am desperately waiting for this to be resolved as need it for my functions... Also, as a side note... I deployed my test code above to an app in Azure and messages are not even coming in at all.. Looking at the logging it appears this is due to authentication as can be seen from below error. Is authentication not handled when using external messaging? I can't see anything in the docs implying I have to authenticate in order to send messages using Send-DurableExternalEvent, especially when the messages are coming from activities within the same orchestration ? Same code simply works locally...
Any insight on either above questions would be much appreciated. |
Hi @Ruankr, Sorry for the inconvenience, we'll find your a solution. If you're referring to these PRs ( Azure/azure-functions-host#8694 and Azure/azure-functions-host#8693) those are for ensuring this regression does not manifest in PowerShell 7 (which had not released yet), so that users continue to have that workaround. For PowerShell 7.2 - we have the fix, but we'll need to catch a different release date. I'm working on setting that up. I should have an update as soon as Tuesday next week. So let me outline a few possible workarounds. The first one is to temporarily use PS 7, if that's a possibility for your app. Please let me know if that's the case. The second option should be to revert back your Azure Functions runtime (also called "Host") version to 4.8.0, as that version should not have this regression. You can use the guidance here: https://docs.microsoft.com/en-us/azure/azure-functions/set-runtime-version?tabs=portal#automatic-and-manual-version-updates to revert back your Host version to 4.8.0 I'm going to be testing the second guidance myself shortly. I'll report back on the details asap. Regarding your second question, on the authorization bits: can you please provide me with a I'll also be writing a regression guidance post on this shortly. I'll link it to this thread. |
I'm still experimenting with PowerShell 7.2 workarounds, but I can confirm that PowerShell 7.0 seems to work as expected. This is rather strange. Will continue this thread posted. @Ruankr: can you please confirm if PowerShell 7.0 is a viable temporary workaround for you? |
@davidmrdavid Unfortunately I cannot use Powershell 7 due to some dependencies only available in 7.2. I'm looking at using storage tables as a temporary workaround in the mean time however it's getting messy so ideally would like to stick to external events. My test code I am using to play around with is here: https://github.com/ruankr/azure-durable-funcevents I've worked in a workaround in Hello3 for the messages in azure using the function key which seems to work, however its not clean as have a dependency on the key being either in keyvault or added to the function itself (which is problematic using terraform). I can work around this though, just thought it would not require authentication being "internal" calls. |
Hi @Ruankr: Does your authentication workaround for Hello3 also resolve the original issue of the non-determinism exception? From my analysis so far, I am fairly certain that the core faulty component is non-deterministic loading of external events data in 7.2. As a result, even with the authentication solved, I am not certain that external events will work properly. The external storage tables sound promising, but I'd need more details to provide guidance. Still pursuing workarounds, will keep you posted. |
@Ruankr: it would help me to understand when exactly this started failing for you. If you had an app that was working before, and then it started showing this error - can you please provide me the earliest timestamp of this issue in UTC? |
@davidmrdavid The authentication workaround works but the external events still do not get picked up. It's a new issue as I've only recently had the need to report back from another long running instance and was looking what best to do, external events seems to fit for what I need, if it worked... |
Understood, that fits what I expected would happen as well. My recommendation at this point would be to split your workflow into separate orchestrators, split by what would have been the external event call. Then, you can have your long running process simply fire an event when completed (an HTTP request, writing to a queue, writing to storage, or just any other Functions Trigger) and to use that event to fire the next orchestrator in the sequence. It's rather manual, but I think this would work as a workaround. I'll continue looking for alternatives and pushing for a resolution of the issue on Azure in the meantime. |
Yep, that's what I am doing already by means of storage queues. It is messy though as I have to use custom powershell to add/remove messages etc but its a workaround for now. Appreciate your help with the events though, will be nice to get a solution at some point ;) |
Hi @ruankrTs - thanks for dropping the issue! I'm a PM working on Durable Functions and would love to learn about your experience using DF PowerShell. If your time allows, please grab a meeting with us here. Understanding the problems you're trying to solve will help us target future development. Thanks! |
It seems there is inconsistency and breakage with external event handling when using Powershell 7.2 in Azure functions.
HttpTrigger
Orchestration function
Hello (Activity)
Bye (Activity)
Using the above code when I do:
"FUNCTIONS_WORKER_RUNTIME_VERSION": "~7"
It works and will run Bye and produce the correct output. However, when I change it to:
"FUNCTIONS_WORKER_RUNTIME_VERSION": "7.2"
It stays in the running state and does not run Bye. Sending the 2 events manually again, it throws an exception below:
If I make the orchestrator slightly complicated:
Orchestration function
Hello1 (Activity)
Then it again does not complete unless I resend the events, but this time I sometimes have to send the events multiple times before it fails again (using ~7 still works though). The more complex the orchestration the more inconsistent it seems to get.
Core Tools Version: 4.0.4736 Commit hash: N/A (64-bit)
Function Runtime Version: 4.8.1.18957
When using ~7 it runs PowerShell 7.0.11
When using 7.2 its running PowerShell 7.2.4
Am I doing something wrong?
Anyone else have success running external events with PowerShell 7.2 when using complex orchestrations?
The text was updated successfully, but these errors were encountered: