What happens when a new pending activation interrupts long poll?

[Sushisource]

See original discussion here: #89

We need to test and determine best course of action when a new PA interrupts a poll. Ideally it should cancel the request, but there are many potential weird corner cases here like what to do if things race and we somehow get a new task back but don't acknowledge it.

[bergundy]

Does this happen when we receive a workflow task that triggers multiple "sequential" activations and haven't sent them all out to lang while lang polls for the next workflow task?
Perhaps it would make more sense to split polling into 2 methods:
poll_workflow_task_for_specific_workflow
poll_any_workflow_task

Or maybe when a workflow activation completes core responds with next pending activation if one is available.

We should think about it.

[bergundy]

Maybe buffering the poll response from the server is a better way to go here.
It keeps the interface simple and the only downside I see is that lang might not pull the buffered task fast enough to avoid WFT timeout.
This might not be such a bad thing considering that lang controls the WFT poll limits.

[Sushisource]

I'm worried buffering just opens up too many corner cases. You have to deal with the timeout you mentioned, but also that the buffered poll could be for a different task queue than the one you just asked to poll, etc etc.

But.....

Vitaly and I had talked before about potentially responding to completions with new pending activations. We decided against it initially because it felt a little unpleasant to have to have a whole new control flow for that. But, it does solve this problem handily, and the "different task queues" problem actually already exists for Pending Activations and it would solve that too. So, that might be a nice way to kill two birds with one stone. It does make things way more clear in that "poll" now always means "yes, actually poll the server" and frankly it'd probably make a bunch of what I am doing in #93 easier. @vitarb What do you think?

[bergundy]

What if we just respond with all pending activation to the poll request? Is there a reason not to do that?

[Sushisource]

What if we just respond with all pending activation to the poll request? Is there a reason not to do that?

Per discussion in call: Not possible. We need lang to reply with appropriate commands during replay to check against history.

[mfateev]

Note that synchronous reply can take a long time if the core has to retrieve the next page of a history from the service.

[bergundy]

That's not an issue for node and python at least because the api call does not block a thread.

…

On Wed, Apr 14, 2021, 21:46 Maxim Fateev ***@***.***> wrote: Note that synchronous reply can take a long time if the core has to retrieve the next page of a history from the service. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMYUBBO6G37B6ZGELDKJ3TIXPIJANCNFSM422DXRYA> .

[Sushisource]

The exported functions are already defined as async anyway - so any Rust glue with whatever language would turn it into that language's async mechanism or if one does not exist, into a callback or something.

[mfateev]

OK. If this mechanism can handle such delays I don't have a strong opinion. If you feel that it simplifies Lang SDK development I would not oppose it.