What the engine is
Behind StretchAutomate's UI sits a dedicated compute engine that does the hard graph and data work. The engine is stateless: StretchAutomate remains the system of record for your workflows, steps, connections, and runs, while the engine performs pure computations on demand. It powers four capabilities — validate, plan, evaluate‑step, and retry‑policy — and it is what makes runs, publishing, validation, and planning possible.
The four engine capabilities
Validate Given a workflow definition (its trigger and steps), the engine returns whether the graph is valid, along with any errors and warnings. This is the check behind the Validate & Plan tab and the gate behind Publish. The latest validation result is saved onto the workflow as a snapshot.
Plan The engine computes the execution plan — the topological stages the run executor will walk. This confirms ordering and reveals which steps run together. Planning is also performed automatically at the start of every run.
Evaluate‑step The engine can evaluate a single step against a supplied context without running the whole workflow. It resolves the step's templated inputs, reports any unresolved references, and — for filters — reports which rules were evaluated and whether they passed. This powers the per‑step resolution during a run and can be used ad hoc to test one step in isolation.
Retry‑policy The engine computes retry behavior — given an attempt count and a policy, it determines whether and when a failed step should be retried (the next retry time). This is what populates the retry columns you see in the Run ledger. See Retry Policies and Error Handling for how to use it.
Checking engine status
StretchAutomate exposes an engine status view that reports the engine's configuration and, when it is enabled, a live health check. Administrators use it to confirm the engine is reachable and running. If the health check reports an error, the engine is enabled but the compute service is unreachable — a signal to check the engine deployment.
Enabling the engine
The engine is gated and additive: nothing calls it until an administrator turns it on (by setting the engine mode to the Python engine in the platform configuration). This lets the rest of StretchAutomate — browsing workflows, editing steps, managing connections — work independently of the compute service.
When the engine is enabled, validation, planning, ad‑hoc evaluation, retry computation, publishing, and runs all use live engine results.
How the app behaves when the engine is off
StretchAutomate degrades gracefully so a disabled engine never breaks the app for reading:
- Reading validation or the plan (the Validate & Plan view) still works: it returns the last persisted validation snapshot if one exists, or a clear note that live results require the engine. The plan view reports that stages cannot be computed until the engine is enabled. No hard error.
- Actions that require compute — running a workflow, publishing, ad‑hoc step evaluation, and retry computation — are blocked with a clear message that the engine is not enabled. These need live compute and cannot fall back to a snapshot.
The practical rule: you can build, edit, and read everything without the engine, but to run, publish, or get live validation you need it enabled.
Realistic example
A team builds several workflows while the engine is off. They can create workflows, add steps, wire dependencies, and read the Validate & Plan tab (which shows the last saved snapshot or a note). When they try to run a workflow, they get a clear message that the engine is not enabled. Their administrator enables the engine, checks the engine status view and sees a healthy response, and now the same workflows validate live, plan into stages, and run — producing full traces in the Run ledger.
Tips
- If runs or publishing suddenly stop working with an engine not enabled message, the engine mode was turned off — confirm with your administrator.
- Use the engine status view to distinguish disabled (mode off) from enabled but unhealthy (compute service unreachable). They need different fixes.
- Because validation snapshots are persisted, a workflow you last validated while the engine was on still shows that result when the engine is later turned off.
- Engine computations are pure — validating or planning repeatedly is safe and has no side effects.
Troubleshooting
"StretchAutomate engine is not enabled." The engine mode is off. Ask an administrator to enable it; until then, runs, publish, ad‑hoc evaluate, and retry computation are unavailable.
Engine status reports a health error. The engine is enabled but the compute service can't be reached. Check that the engine service is deployed and running.
Validation looks stale. With the engine off you are seeing the last persisted snapshot. Enable the engine to recompute against the current graph.
Was this helpful?
Help us improve this article
Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.