I would suggest you setup a local instance and test there to see if the issue is with Corteza or your server configs.
I’ve been running some quite heavy-duty workflows not so long ago and they went through without timing out.
There has however been a feature that would cause workflow execution to crash due to high memory consumption.
Workflow execution keeps a stack trace but it is a bit too verbose and coupled with long executing workflows, the memory consumption can be high.
In 2022.3.0 we’ve added a WORKFLOW_STACK_TRACE_ENABLED which would allow you to disable stack traces.
If your instance crashes due to no more memory errors, you have the following options:
Disable the stack trace
Use the above .env variable to disable stack traces; not ideal but is quite acceptable for some cases.
Split up the work
Utilize the messaging queues to have different workflows perform smaller subsets of work.
We don’t have much docs for how to do this, but the TL;DR of it is:
- in the admin panes, messaging queues; define a new queue where the consumer is set to event bus
- in workflow A, use a function step where the function is “queue message send”
- in workflow B, use a trigger with resource of “system queue” and event “on message”.