windmill-labs/windmill · warning

Failed to upload scripts to temp storage (backend may be too

Error message

Failed to upload scripts to temp storage (backend may be too old): ${e}. Locks will be generated using deployed script versions only — locally modified relative imports may not be reflected.

What it means

During lock generation, wmill uploads local scripts (dependency tree) to temporary storage so locks can include locally modified relative imports. If the upload fails — typically because the connected backend predates the temp-storage endpoint — it falls back to generating locks from deployed script versions only and warns that local modifications to relative imports may not be reflected.

Source

Thrown at cli/src/commands/script/script.ts:1816

    tree.setWorkspaceDeps(rawWorkspaceDependencies);
    for (const e of Object.keys(elems)) {
      await generateScriptMetadataInternal(
        e,
        workspace,
        opts,
        true, // dryRun: populate tree
        true,
        rawWorkspaceDependencies,
        codebases,
        false,
        tree,
      );
    }
    tree.propagateStaleness();
    try {
      await uploadScripts(tree, workspace);
    } catch (e) {
      log.warn(
        colors.yellow(
          `Failed to upload scripts to temp storage (backend may be too old): ${e}. ` +
            `Locks will be generated using deployed script versions only — locally modified ` +
            `relative imports may not be reflected.`,
        ),
      );
    }
    for (const e of Object.keys(elems)) {
      await generateScriptMetadataInternal(
        e,
        workspace,
        opts,
        false,
        true,
        rawWorkspaceDependencies,
        codebases,
        false,
        tree,

View on GitHub (pinned to e474e8803c)

Solutions

1. Upgrade the Windmill backend to a version matching the CLI so temp script storage is supported
2. Regenerate metadata after upgrading if local relative imports must be reflected in locks
3. If you have locally modified relative imports, push those dependencies first, then regenerate locks
4. Check connectivity/auth if the cause is not an old backend

Example fix

// before
# docker.getwindmill.com image: ghcr.io/windmill-labs/windmill:v1.400 (too old)
// after
# ghcr.io/windmill-labs/windmill:latest  # upgrade backend, then
wmill generate-metadata

const v = await wmill.getBackendVersion(); if (semver.lt(v, MIN_TEMP_STORAGE_VERSION)) console.warn('locks will use deployed versions');

try { await generateMetadata(); } catch (e) { console.warn('falling back to deployed-version locks'); }

When it happens

Trigger: Running `wmill generate-metadata` (or the flow-lock generation path) against a self-hosted backend older than the temp-storage feature; an error thrown by uploadScripts (network, permissions, API mismatch).

Common situations: Self-hosted Windmill instances lagging behind the CLI version; partially upgraded clusters; transient API errors during generation.

Related errors

• Cannot regenerate lock for flow ${remote_path}: missing inli
• Failed to queue flow dependencies job: ${queueResponse.statu
• Failed to poll flow dependencies job ${jobId}: ${e?.message
• Failed to generate lockfile: ${message}
• Failed to generate lockfile: ${message}

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