RaiseEvent-Call doesn't transmit content/body to Orchestrator

Hello, I’m running a durable function with the human interaction pattern like in the human interaction example . I successfully raise the event in a separat azure function via a HTTP call according to the documentation. In line 22, $approvalEvent, the return value of the Start-DurableExternalEventListener is used as the input for the activity. I assume that that’s the value of the body that’s send with the HTTP-call to raise the event, although it is not actually used in the activity itself in the example. I managed to capture the message in the queue, and the body is in there under TaskMessage.Event.Input. If I convert the $approvalEvent to JSON, it is just "{}". Is the message body not available in powershell or is there a cmdlet to query the data? The documentation is incomplete on this so far.

Please let me know if I can provide further information! Thank you!

Best regards, Oliver

[davidmrdavid]

Hi @oobegreg, so sorry for my delayed response, there’s been a lot going on, so I actually do have quite a bit to share.

In short, the original issue described in this thread (external events not returning their input when the task completes) can be fixed independently on the Get-DurableTaskResult CmdLet you proposed. In fact, I have a working branch where I’ve included the fix here: https://github.com/Azure/azure-functions-powershell-worker/blob/506e4f78564fe0b3d71bf1e7705c9bf522c17ce5/src/DurableSDK/DurableTaskHandler.cs#L64-L71

However, your proposed CmdLet (and associated changes in your fork) is in fact a missing feature that we urgently need, and I do want to merge it into the repo (I really appreciate your contribution and the implementation seems sound!), but given that it represents a new public API, and the fact that PowerShell’s Durable Functions APIs is already so unique, it will require just a bit more time before we’re ready to do so. Given that I don’t have direct control over these timelines, I’d like to avoid giving an ETA on that to properly manage expectations here. That said, I’ve opened a PR to merge your changes here - https://github.com/Azure/azure-functions-powershell-worker/pull/753

I also want to clarify where I’ve been spending my development time here, because I realize that this particular issue may seem like an easy fix . In general, as I mentioned earlier in this thread, the team is investing heavily in the implementation of a new deployment strategy that should allow us to release bug fixes and new features to the PowerShell DF SDK at a faster rate than is possible today, and most of my time has been invested in there. While still very much in development and not ready for review, you can see a tiny part of that effort in this PR: https://github.com/Azure/azure-functions-powershell-worker/pull/746/files

In general, we’re working to extract the Durable SDK out of the worker and make it into its own package to be eventually released in the PowerShell gallery (or something like it). So in addition to the worker-level changes that exist in this PR, we have a private repo where a mirror’ed SDK is being developed. In any case, I’ll be incorporating the bug reports listed in this repo as fixes in both this and the mirror’ed SDK, but right now we’re prioritizing being able to have that separate and fast-to-release SDK as the first step to fixing some of these bugs. The good news though is that this week we made serious progress towards finishing that effort, so I believe it won’t be long until we’re in a good position to make hotfix releases without any external delays.

And that’s been it! I appreciate your patience, and I’ll push to get that PR of your fork merged asap

[davidmrdavid]

Hi @oobegreg,

I want to make sure we have the same starting context: when using the -Any flag, the result of a Wait-DurableTask should return a Task object instead of the result. You pointed this out in your description, but I wanted to make sure we were in the same page on this being the intended behavior 😃 .

With that in mind, the missing step would then be to obtain the result data from within that Task. I haven’t managed to test this yet, but I would have expected that calling Wait-DurableTask again on that object should yield the result. I do realize we should have a better means of doing this, I’m still exploring whether that already exists in the codebase.

If using Wait-DurableTask on the task object doesn’t work, then I do think we should incorporate your Get-DurableTaskResult command, or something very much like it.

@oobegreg: had you tried using Wait-DurableTask on the result of Wait-DurableTask with -Any? Did that work for you?

As for a timeline for a fix, I think the earliest I could merge a fix would be around Wednesday next week. After that, we’re tied to the release schedule of the PowerShell Azure Functions worker, and that can take a few weeks. That’s why I want to first explore whether there are any means of extracting this result from within the existing codebase as well; it can be a fair wait otherwise.