Polls are scoped by a positive marker, defined once
Scoping by the presence of a trigger configuration served cron, entity and form runs (output data included) to any external platform that asked.
The rule
- A poll answers only runs that were externally invoked, identified by a positive source marker carried in the run's initial data.
- Scoping must not be inferred from the presence of a trigger configuration identifier, which every trigger kind sets.
- The marker has exactly one definition, shared by the code that writes it and the code that reads it, so producer and consumer cannot drift apart, a drift that manifests as a poll returning nothing forever, with no error.
- The marker travels in the run's initial data, not in the options that configure the orchestrator, which never reach it.
What it means
Every trigger kind stamps a configuration identifier onto the run it starts, so that identifier cannot be what a poll selects on — scoping by it would answer with every internally triggered run alongside the externally invoked ones. The marker that does the selecting is written in exactly one place and read in exactly one place; if the two ever disagree, nothing raises an error. A poll simply returns nothing for a run that should have been visible, and keeps returning nothing, because there is no failure for anything to report.
Example
Three completed runs of three workflows, orch_workflow, cron_workflow and
manual_workflow. Only the first was started by an external caller; the
second was started by a scheduled trigger and so also carries a trigger
configuration identifier, but not the marker; the third was started by hand:
{
"source": "orchestration",
"trigger_config_id": "orch_workflow__orchestration_trigger_1",
"payload": { "title": "external" }
}{ "trigger_config_id": "cron_workflow__entity_trigger_1" }{}["orch_workflow"]