⚠ server-side lock generation FAILED for

Error message

⚠ server-side lock generation FAILED for ${f.path} — the deployed script is broken until it locks.${f.error ? "\n  " + f.error.split("\n")[0] : ""}

What it means

After `wmill sync push` applies changes, the CLI asks the server to generate locks for each deployed script (checkServerLockJobs). If lock generation failed for a file, this warning names the path and the first line of the server-side error. A deployed script without a valid lock is broken — it cannot execute — until it locks, so this warning should be acted on despite its log level.

Solutions

Read the first line of f.error shown under the warning for the concrete lock failure.
Fix the script's dependencies (e.g. remove/replace the failing requirement) or fix the reported syntax error.
Re-push just the affected script (`wmill push <path>`) or re-run sync to regenerate the lock.
If lock generation times out, reduce dependencies or check the server's lock/worker service health.

Example fix

// before (requirements.txt of the failing script)
numpy==2.0.0
pandas==1.5.0  # incompatible with numpy 2.0 → lock fails
// after
numpy==1.26.4
pandas==2.1.4

Defensive patterns

Strategy: validation

Validate before calling

// Validate script dependencies locally before push:
// Python: pip install -r requirements.txt && python -c 'import module' in a clean venv
// TypeScript: bun/npm install and type-check the script entrypoint

Try / catch

const lockJobs = await checkServerLockJobs(workspaceId, startedAt, paths);
for (const f of lockJobs.failed) {
  console.error(`${f.path} deployed WITHOUT lock — fix and re-push: ${f.error?.split('\n')[0]}`);
  process.exitCode = 1;
}

Prevention

Pin mutually compatible dependency versions in requirements.txt / package.json
Smoke-test dependency installation in CI before sync push
Keep dependency lists minimal to avoid lock timeouts
Monitor worker/lock service health on the server
Treat this warning as blocking — the script is broken until it locks

When it happens

Trigger: Server-side lock generation (dependency resolution/compilation for Python/TypeScript etc.) fails for one or more pushed scripts — e.g. unsatisfiable dependencies, syntax errors in the script's entrypoint, or lock service timeout.

Common situations: requirements.txt/pyproject.toml pinning incompatible packages; TypeScript scripts importing packages that don't resolve; oversized dependency sets timing out; pushing a script with a top-level error.

Related errors

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

Appendix: source

Thrown at cli/src/commands/sync/sync.ts:6548

        newDatatableMigrations,
        {
          yes: opts.yes,
          jsonOutput: opts.jsonOutput,
        },
      );
    } catch (e: any) {
      log.warn(
        `Failed to run new datatable migrations: ${e?.body ?? e?.message ?? e}`,
      );
    }
    const lockJobs = await checkServerLockJobs(
      workspace.workspaceId,
      pushStartedAt,
      changes.map((c) => c.path.replaceAll(SEP, "/")),
    );
    if (!opts.jsonOutput) {
      for (const f of lockJobs.failed) {
        log.warn(
          `⚠ server-side lock generation FAILED for ${f.path} — the deployed script is broken until it locks.` +
            (f.error ? `\n  ${f.error.split("\n")[0]}` : ""),
        );
      }
      if (lockJobs.pending > 0) {
        log.info(
          colors.gray(
            `${lockJobs.pending} server-side lock job(s) still running — locks (and inferred assets) land when they finish; check the Runs page if a script stays broken.`,
          ),
        );
      }
    }
    const pushedCount = changes.length - failedChanges.length;
    if (opts.jsonOutput) {
      const result = {
        success: failedChanges.length === 0,
        lock_jobs: lockJobs,
        ...(failedChanges.length > 0 ? { failed: failedChanges } : {}),

View on GitHub (pinned to e474e8803c)