Update documentation on agent style limitations

[davidglassborow]

I'm trying to write a Serverless implementation of an Alexa Skill endpoint and/or a Twilio phone call endpoint.

In both cases:

• An external system calls a user defined endpoint via HTTP with the first call in the sequence
• The users endpoint returns a command back to the external system
• At a later point (prehaps only a few seconds) we get another HTTP call with further input for the 'conversation'
• The process can carry with request and responses until the conversation has ended

This pattern is required in many of the webhooks / integration / extension features of various SaaS products.

An example sequence diagram for a user on a call to a software phone system, where 'Our API' is returning TwiML, an XML variant, describing what the phone exchange should do next ( e.g. speak a message to the user, ask them to type in a number of the phone key pad, etc ).

I'm attempting to use azure functions to implement the 'Our API', using a DF to hold the ongoing state of the 'conversation'.

The more I think about it, I wonder whether this can be implemented on durable functions:

• The external system ( e.g. Alexa, Twilio ) needs a response straight away.
• It will send a unique conversation id, so we can use that for creating an unique identifiable orchestrator
• The external system will call the end point more than once over the sequence of a 'conversation' and will need a result each time
• An Azure Function can wait on an orchestration's answer, but only when the orchestration is complete, so essentially only one response.

I think to have something in DF that would allow us to model these sorts of processes, we would need the ability for an orchestrator function to respond to external events (this feels like #22) or maybe Orchestrator functions to support returning something like an IAsyncEnumerable (as a generalisation of Task), allowing it to 'yield' multiple responses.

I hope the question makes sense, and maybe I've missed how we could implement this sort of requirement on Durable Functions.

Thanks.

[cgillum]

This seems like a fine fit for Durable Functions to me. It's not unlike the Human Interaction / Phone Verification sample that we currently have. As long as the Twilio API can pass you the state you need to raise events to your orchestration, then this should be straight forward to implement.

[davidglassborow]

I thought so at first, but in that sample, the orchestration is pushing the SMS out when it decides to, it's not responding to an incoming call.

For a voice Twillio call, I need to handle multiple (over time) HTTP calls, respond to them synchronously, all within one over all orchestration, and I can't work out how to do that with DF.

[davidglassborow]

Another way of explaining the issue I'm having is:

There are 2 ways for an orchestrator to receive data from the outside world:

• The initial data it's created with via DurableOrchestrationContext.GetInput
• Events sent to it via DurableOrchestrationContext.WaitForExternalEvent

It can also obviously look up data from the outside world via DurableOrchestrationContext.CallActivityAsync

However from the outside world, the only call to retrieve information from the orchestrator is DurableOrchestrationClient.WaitForCompletionOrCreateCheckStatusResponseAsync and that only retrieves it's completed result.

I've linked to the definitions in source code, because I can't seem to find the references in the docs anymore since the reshuffle.

i.e. How would you change the PhoneVerification example so an incoming HTTP call trigger could establish how was along the verification was (e.g. has the SMS been sent ? if so how many times ? how long ago was it last sent ?)

The only work around I've come up with so far is to:

• The incoming HTTP call sends an event to the orchestrator
• It then busy waits on a result via a custom status via the status API

Equally this could be done by getting the ochestrator to write the 'event response' into an azure queue and have the HTTP poll on that, but again its polling with potentially race conditions etc, and it loses a lot of the benefits of using DF in the first place.

[davidglassborow]

An example blog of where someone is using the custom status / polling approach: https://blog.mexia.com.au/async-http-apis-with-azure-durable-functions

[davidglassborow]

@cgillum I think it's right to say:

• DF can only react asynchronously to events from the outside, not synchronously
• The only exception to this is the builtin feature of an azure function using DurableOrchestrationClient to async/await on termination of the DF

My use case involves synchronously reacting, hence my confusion.

I can understand this limitation ( removing this is essentially moving to a complete actor model like #22 ), but is it worth me raise a PR to the documentation to make this clear ? ( as suggested in the actor thread )

[cgillum]

@davidglassborow Yes, you are basically right. I didn't realize you needed the subsequent calls from the phone to be synchronous (request/response). As you already mentioned, one can work around this limitation using the custom status polling approach (and we use this successfully in some of our test automation), but it's not as clean of an approach and would involve a small amount of additional latency.

[davidglassborow]

And presumably cost as there is no way to async/await on the custom status api.

Is it worth updating the docs ? would you like me to raise a PR ?

[cgillum]

Can you clarify what you mean when you say there is no way to async/await on the custom status API? Do you mean, having an api like DurableOrchestrationClient.WaitForCustomStatusAsync()? We could certainly look into that as a feature, or add documentation for how someone could implement that themselves (we have a semi-example here).

If you would like to submit a PR, I'd be happy to review and approve it.

[davidglassborow]

Yes that's the sort of thing. Your semi-example is just checking for an expected status, so if we wanted to use the status as a reply channel, we'd have to think how do we encode that it's a new status (i.e. a reply to the current request) and not whatever the last reply was. I guess something like a version id or a correlation id held against the status.

Happy to raise a PR on the docs, I was planning to some notes about request/response to https://docs.microsoft.com/en-gb/azure/azure-functions/durable/durable-functions-singletons, but is this file in the repo or one of the doc repos, would you mind pointing me the right direction ?

[cgillum]

Documentation on docs.microsoft.com is in the MicrosoftDocs GitHub repo. Rather than trying to find that repo, though, you should be able to make a PR submission from the documentation page directly (see the Edit button towards the top of each docs page).

[davidglassborow]

I've raised a PR through github @cgillum (easier than creating yet another account to edit via the docs page) - https://github.com/MicrosoftDocs/azure-docs/pull/20638

[davidglassborow]

@davidglassborow Yes, you are basically right. I didn't realize you needed the subsequent calls from the phone to be synchronous (request/response). As you already mentioned, one can work around this limitation using the custom status polling approach (and we use this successfully in some of our test automation), but it's not as clean of an approach and would involve a small amount of additional latency.

@cgillum I've just seen your post on the new Durable Entities. Sound like they would support subsequent synchronous (request/response), right ?