When querying process instances and variables through the operate API, we see inconsistencies (I know that this is by design), e.g. the process instance is found to be completed but when we fetch the variables for this process instance, we do not see the latest values right away.
Is there a way to know if all events for a process instance have been ingested into operate once the instance has been completed? E.g. a version or timestamp to compare? (i.e. I want to know if operate has reached the eventually consistent state :-))
Or is fiddling with the exporters bulk settings the only way to get closer to this?
Hi @pas, welcome to the forums! This is an interesting question! I don’t know of any flags that are available today, but I’ve asked our product team if they have any thoughts on this.
In the meantime, what’s your use case? Are you just monitoring running processes outside Operate? Or does your application have a need for that data when the process ends in close to real time? There might be some alternatives that would work better than fiddling with the exporter (for instance, process end event execution listeners).
Yes, we are monitoring processes from the outside and did not want to add listeners to each process - since this monitoring is not part of it.
Since there is no guarantee to have a consistent snapshot within operate, we might need to reconsider this idea and look into listeners.
For now we tweaked the exporter settings and potentially add some grace period once a process instance is finished before we read the variables (these are long running processes, adding some seconds of delay does not have any effect)
Hello @pas - I chatted with some of our engineers, and there’s two important things I learned:
Operate has its own importer to normalize the exported data for its operations; this happens asynchronously and is probably causing additional delay.
The final record exported from Zeebe is a “COMPLETED” event, and this is exported after all other data has been exported: once that record is written, that is the trigger for Zeebe to delete the PI from its internal database.
As of today, there are three options/workarounds:
Do what you’re doing now, with a slight polling delay, or some variation of that;
Use the execution listeners, which can share a single job worker for execution, but you would need to add the listener to each deployed process;
Implement a custom exporter and trigger an event in your application when you see that “COMPLETED” record.
In the future - tentatively the 8.9 release next spring - we will support global listeners, which would be the best solution for this. But as of right now that feature is still in development.