harshadmanglani

Fair enough, will do. Thanks!

Thanks for sharing! I'll check it out.

Thanks for sharing this! There is no support for timeouts yet, but might be a good addition.

Can you elaborate on what you mean by modelling non-centralized things?

Super helpful feedback @peter. Thanks a ton!

I've noted all of these and I'll modify the README to include them. Thank you for taking the time to go through in such detail :)

Given that the current state of a workflow:

- is inherently invisible

- all we can really check in the DB is if, for a workflow, the available data contains the target data;

how would I address observability concerns?

This is a function of a lack of workflow states due to the lower levels of abstraction it operates on. User defined workflow states would do the trick, but I suppose that would take writing some more code after integrating the framework.

Thanks for the inputs! I'll add some examples in the documentation.

- with control on the database reader yourself, i think you should be able to find a way around saturation/desaturation?

- again, the fairly certain you can limit DB readers in the DataStore interface you pass to the orchestrator. I'll think about the cpu and memory share and if there's a way to expose that.

A major concern I've always had with workflow orchestrators is the versioning of workflows. Think about long running workflows (>2 days). If you change your workflow logic, what happens to the existing ones that haven't completed yet?

Everyone handles this differently, and I've been thinking about a generic way to do this. Thoughts?

thanks for sharing this. that's what @withinboredom mentioned too :)

Let me add a license, I missed it. Thanks for pointing it out!