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

  1. Re-run the command — the underlying job may have completed; check the run in the web UI by job id
  2. Fix connectivity/credential issues surfaced in the inner `e.message`
  3. Increase client timeout allowances or retry in CI with backoff
  4. 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

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


AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/654160a43ed2858c. Report an issue: GitHub.