windmill-labs/windmill · error · LockfileGenerationError
Failed to poll flow dependencies job ${jobId}: ${e?.message
Error message
Failed to poll flow dependencies job ${jobId}: ${e?.message ?? e} What it means
After the flow dependencies job is queued, the CLI polls it with pollJobWithQueueLogging; any exception raised during polling (network failure, auth rejection, unexpected API shape) is wrapped as this LockfileGenerationError with the job id and the underlying message.
Source
Thrown at cli/src/commands/flow/flow_metadata.ts:500
try {
bodyText = await queueResponse.text();
} catch { /* ignore */ }
throw new LockfileGenerationError(
`Failed to queue flow dependencies job: ${queueResponse.status} ${queueResponse.statusText}, ${bodyText}`
);
}
const jobId = (await queueResponse.text()).trim();
let completion;
try {
completion = await pollJobWithQueueLogging(
workspace.workspaceId,
jobId,
{ label: `flow deps ${remotePath}` },
);
} catch (e: any) {
throw new LockfileGenerationError(
`Failed to poll flow dependencies job ${jobId}: ${e?.message ?? e}`
);
}
const result = completion.result as any;
if (!completion.success) {
const message =
result?.error?.message ??
(typeof result === "string" ? result : JSON.stringify(result, null, 2));
throw new LockfileGenerationError(`Failed to generate lockfile: ${message}`);
}
return result?.updated_flow_value;
}
View on GitHub (pinned to e474e8803c)
Solutions
- Re-run the command — the underlying job may have completed; check the run in the web UI by job id
- Fix connectivity/credential issues surfaced in the inner `e.message`
- Increase client timeout allowances or retry in CI with backoff
- Ensure workers are healthy so dependency jobs complete quickly
Example fix
// CI before wmill flow generate-locks f/etl // after for i in 1 2 3; do wmill flow generate-locks f/etl && break || sleep 30; done
Defensive patterns
Strategy: retry
Validate before calling
// Verify reachability before starting a long poll
await fetch(`${baseUrl}/api/version`, { headers: { Authorization: `Bearer ${token}` } }).then(r => { if (!r.ok) throw new Error('instance unreachable'); }); Try / catch
try {
await generateLocks();
} catch (e) {
if (String(e).startsWith('Failed to poll flow dependencies job')) {
// check the job in the UI by id before re-queuing; the job may have finished
await backoffRetry(() => generateLocks(), 3);
}
} Prevention
- Run from networks with stable connectivity to the instance
- Ensure token lifetime exceeds the worst-case lockfile generation time
- Avoid server restarts during deploys
- Set generous HTTP timeouts in the CLI environment
When it happens
Trigger: Polling a queued flow-deps job throws: transient network drop, 401 mid-poll after token expiry, job purged before completion, or pollJobWithQueueLogging rejecting on an unexpected response.
Common situations: Long lockfile generation exceeding client-side timeouts; flaky VPN/proxy in CI; token with read-expiry shorter than the job; server restart while the job was pending.
Related errors
- Failed to poll dependencies job ${jobId}: ${e?.message ?? e}
- Giving up polling job ${jobId} after ${MAX_CONSECUTIVE_POLL_
- Failed to poll dependencies job ${jobId}: ${e?.message ?? e}
- Could not auto-fill missing lockfile entries: ${e instanceof
- Dependency generation failed: ${queueResponse.status} ${queu
AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03).
Data as JSON: /api/errors/654160a43ed2858c.
Report an issue: GitHub.