Hi,
Is there a way to maintain execution context for the workflow tasks, similar to the executionContext in SWF, and if so, how to read/write using the gRPC API?
Thanks!
Instead of the SWF executionContext use more powerful Temporal query feature.
The queries could be more powerful for some use cases, but my use cases require light-weight storage, that changes as part of the workflow task, and used mainly for generic workflow controlling logic.
One example for that is storing additional information on a command (e.g. controlling logic on the start timer command to be used later when the timer fires). a mutable context, received by the workflow task, mutated, and returned in the response would be a good solution
All the variables in the workflow code are already durable. So there is no need to store any additional information in the context.
Not sure I understand what you mean by that. the workflow code (i.e. the workflow task processing) can be done by different workers running on different servers. how would the data be shared between them without context (or something else) on the workflow itself? in addition, what will happen if the worker restarts?
These are implementation details of the Temporal service and SDKs. But as an application programmer the whole state of the workflow execution is fully durable and is not linked to any particular worker process. So your workers can be restarted or scaled up/down at any time and all the data in the workflow code will be preserved. This is the main value proposition of Temporal.
Then perhaps I’m missing something…
from what I understood so far, the entire workflow’s state is encapsulated in the workflow’s execution events history, which is passed to the workflow task in the polling response.
any additional mutable state I can access using the temporal service through gRPC APIs?
Yes, it is encapsulated in the workflow history and passed to the workflow task in the polling response. But all of this is done by the SDK libraries and you as an application developer don’t need to think about this. Have you looked into Temporal SDKs documentation?
Yes, I did, however, since I’m using typescript, and the nodejs SDK is not released yet, I cannot use it.
In addition, I provide a layer on top of both SWF and Temporal, to allow common functionalities on top of the provided workflow capabilities, so I prefer to work with lower level APIs.
Still assuming that the workflow task processing can be non-sticky and technology agnostic, there should be a generic way for any SDK to maintain a mutable (dynamic) context information, and store it with the workflow
I wouldn’t recommend building at the gRPC level. Temporal SDKs are pretty complicated and provide a lot of functionality. You would be in much better place using non released version of Typescript SDK versus rolling your own.
Thanks for the advice!
In general, SDKs seems to be opinionated, for the good and for the bad, in this case I have my own way of doing stuff, and I already have my basic implementation on top of gRPC, which fits the basic needs I have from the API.
The context is one thing I had to work around, and I just was looking for a better way…
It is certainly your choice, but I would not recommend this strategy for anyone who is planning to use Temporal for complex use cases.