A cloud flow that re-triggers itself on every run

Flow writes a column its own trigger filters on.

The trigger watches a specific list of columns and one of the flow's own actions writes one of them, so every run re-queues the flow. The platform's depth limits stop an endless chain, but the logic runs again each time, doubling anything it counts and spending run capacity other automation needs.

Pathix reads the trigger's filtering columns and the flow's own write actions. It does not read trigger conditions, so it cannot tell a flow that has been guarded from one that has not, and this never says the flow is looping right now. Only enabled flows are reported. A trigger with no filtering columns at all is a different finding, because a flow watching every column has no specific list to write back into.

Open the flow and compare the trigger's Select columns box against the columns its own update actions set. Any column in both is the finding. Covers cloud flows and agent flows; the plugin-step version of the same condition is its own check.

Drop that column from the trigger's Select columns list, or add a trigger condition that makes the re-entry a no-op.

This one is environment health, so it carries a plain label and no control mapping. Presenting an operational gap as a security finding would make the real security findings harder to trust, so we keep the two apart.

• A plugin step that re-triggers itself on every save
• Two plugin steps at the same execution order writing one column
• Two flows writing the same column on the same trigger
• A flow calling a child flow that is switched off