Package: @objectstack/service-automation@16.1.0
Companion to #4347, which is the bug this one is about detecting.
Problem
A scheduled flow that selects records and then acts on none looks exactly like a flow that had no work to do. Both:
- report
success: true - emit no log
- run on schedule, every time
- write nothing
There is no signal, anywhere, that distinguishes "nothing to do" from "broken".
This is not hypothetical. In the hotcrm reference app, #4347 left three scheduled flows completely inert — the stalled-deal sweep found every stalled deal and nudged nobody, the renewal sweep never booked a renewal, the campaign enrolment action enrolled nobody. They ran daily, on time, green, for as long as they had existed.
They were caught only by adding runtime tests that assert on records written. Nothing in production could have surfaced it, and no operator could have been expected to notice.
Why this matters more than a normal observability gap
Automation is exactly the category where nobody is watching. A UI bug generates a support ticket within the hour. A scheduled sweep that silently stops working generates no signal at all — the work simply never happens, and the absence of an outcome is invisible. The longer it runs, the more normal the silence looks.
Request
Expose a per-run summary for every flow execution:
- records selected by each data node
- records acted on (created / updated / deleted)
- iterations skipped by a gate, ideally with which gate
- terminal status per node
Surface it in two places:
- Console — a run history view per flow.
selected 30, acted 0 is then obvious on day one. - Queryable — so an operator can alert on it (
selected > 0 && acted == 0 over N consecutive runs is a near-perfect broken-sweep detector).
Note: the engine already has most of this
AutomationEngine carries recordLog, executionLog and listRuns internally, and executeNode already collects steps with per-node results. The information appears to exist already — the gap looks like surfacing rather than instrumentation.
Why the app cannot reasonably do this itself
We considered an app-level detector in hotcrm (counters via assignment, a comparison via decision, an alert via notify) and rejected it:
This belongs in the platform: one implementation, every flow, no per-flow instrumentation.
Suggested minimum viable version
If the full history view is a large piece of work, a much smaller version captures most of the value: log a single structured line per flow run with selected/acted counts. That alone turns an invisible failure into a greppable one.
Related: #4347.
Package:
@objectstack/service-automation@16.1.0Companion to #4347, which is the bug this one is about detecting.
Problem
A scheduled flow that selects records and then acts on none looks exactly like a flow that had no work to do. Both:
success: trueThere is no signal, anywhere, that distinguishes "nothing to do" from "broken".
This is not hypothetical. In the hotcrm reference app, #4347 left three scheduled flows completely inert — the stalled-deal sweep found every stalled deal and nudged nobody, the renewal sweep never booked a renewal, the campaign enrolment action enrolled nobody. They ran daily, on time, green, for as long as they had existed.
They were caught only by adding runtime tests that assert on records written. Nothing in production could have surfaced it, and no operator could have been expected to notice.
Why this matters more than a normal observability gap
Automation is exactly the category where nobody is watching. A UI bug generates a support ticket within the hour. A scheduled sweep that silently stops working generates no signal at all — the work simply never happens, and the absence of an outcome is invisible. The longer it runs, the more normal the silence looks.
Request
Expose a per-run summary for every flow execution:
Surface it in two places:
selected 30, acted 0is then obvious on day one.selected > 0 && acted == 0over N consecutive runs is a near-perfect broken-sweep detector).Note: the engine already has most of this
AutomationEnginecarriesrecordLog,executionLogandlistRunsinternally, andexecuteNodealready collectsstepswith per-node results. The information appears to exist already — the gap looks like surfacing rather than instrumentation.Why the app cannot reasonably do this itself
We considered an app-level detector in hotcrm (counters via
assignment, a comparison viadecision, an alert vianotify) and rejected it:loopare never converted to CEL and the gate silently never opens #4347 — a silent-no-op detector that can itself silently no-op is not a foundation.scriptnodes cannot fill the gap: the built-in runtime treats inlineconfig.scriptas a no-op and logs "no server-side JS sandbox — this node is a no-op". Emitting a summary from a flow requires registering realfunctions.This belongs in the platform: one implementation, every flow, no per-flow instrumentation.
Suggested minimum viable version
If the full history view is a large piece of work, a much smaller version captures most of the value: log a single structured line per flow run with selected/acted counts. That alone turns an invisible failure into a greppable one.
Related: #4347.