⚠ server-side lock generation FAILED for ${f.path} — the dep

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.

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)

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.