Relationships
#1336 Worker queries need a safe connected-worker filter for fleet fan-out
Opened by ehazlett · 7/22/2026· Shipped 7/27/2026
The natural query for building a fleet-wide forEach includes every worker that has enrolled, including disconnected workers:
swamp data query 'modelType == "swamp/worker"' --jsonTested with:
swamp 20260722.020746.0-sha.5d00afa2Example result:
{
"results": [
{
"attributes": {
"name": "worker-01",
"status": "idle"
}
},
{
"attributes": {
"name": "worker-old",
"status": "disconnected"
}
}
]
}A workflow using this query for fleet fan-out creates a placed step for worker-old. Because that worker is unavailable, the step remains queued until queueTimeout expires.
When allowFailure is enabled so that one unavailable worker does not fail the entire fleet operation, the workflow can eventually report success despite spending the full queue timeout waiting for stale workers.
A status filter works once the caller knows that worker status is available under attributes:
modelType == "swamp/worker" && attributes.status != "disconnected"However, the obvious unfiltered query appears suitable for fleet fan-out, and the workflow documentation does not make the historical-record behavior or required status filter apparent.
Requested improvement
Provide a discoverable way to query workers that are currently eligible for dispatch. For example:
workers.connected()or a documented canonical query covering dispatchable statuses.
Additionally, when a step explicitly targets a worker whose last-known status is disconnected, swamp serve could warn or fail immediately instead of waiting for the entire placement timeout.
Impact
A single stale enrollment can turn a short fleet workflow into a workflow that runs for the full queue timeout.
The delayed failure is especially difficult to diagnose when allowFailure absorbs the timeout: the overall workflow can succeed even though it targeted workers known to be disconnected.
Shipped
Click a lifecycle step above to view its details.