Runnable content is still an !inline reference, skipping

Error message

Runnable ${runnableId} content is still an !inline reference, skipping

What it means

While generating app metadata/locks, updateRawAppRunnables walks raw-app runnable definitions. If a runnable's content is still the raw string `!inline <path>` after the replaceInlineScripts pass should have resolved it, the CLI cannot process it as real script content, warns, writes the runnable back unchanged, and skips lock generation for it.

Solutions

Check earlier CLI output for 'Error reading inline path' warnings and fix the missing/wrong !inline paths.
Ensure the referenced script files exist relative to the raw app folder before running generate-metadata.
Re-run `wmill app generate-metadata` from the app root after fixing paths.
If the runnable should contain real content, replace the !inline reference manually in the raw app definition.

Example fix

// before
content: '!inline ./scripts/missing.ts'
// after: file present at that path, then re-run
wmill app generate-metadata  # content resolved to actual script code

Defensive patterns

Strategy: validation

Validate before calling

// before generate-metadata: verify no raw-app file still contains unresolved references
grep -RIn '!inline ' apps/ && echo 'resolve inline references first' || true

Type guard

null

Try / catch

if (typeof content === 'string' && content.startsWith('!inline ')) {
  log.warn(`Runnable ${runnableId} still !inline, skipping`);
  writeRunnableToBackend(runnablesFolder, runnableId, runnable);
  continue;
}

Prevention

Commit all files referenced by `!inline` alongside the raw app definition.
Fix any 'Error reading inline path' warnings before generating metadata.
Run generate-metadata from the raw app root directory.
After cloning a repo, verify inline files exist before locking.

When it happens

Trigger: `wmill app generate-metadata` (or app generate-locks) on a raw app where an inline-script reference was not replaced earlier: replaceInlineScripts skipped or failed for that file (e.g. readInlinePathSync returned '' for a missing file), or the runnable sits in a location the replacement pass does not traverse.

Common situations: Missing inline script file on disk (so the earlier replacement silently failed); nested runnables in unusual app fields not covered by the traversal; freshly cloned repo without the referenced script files; committed raw app YAML whose !inline paths are wrong.

Related errors

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

Appendix: source

Thrown at cli/src/commands/app/app_metadata.ts:515

      !runnable?.inlineScript
    ) {
      // Write non-inline runnables to their own file as-is
      writeRunnableToBackend(runnablesFolder, runnableId, runnable);
      continue;
    }

    const inlineScript = runnable.inlineScript;
    const language = inlineScript.language as SupportedLanguage;
    const content = inlineScript.content;

    if (!content || !language) {
      writeRunnableToBackend(runnablesFolder, runnableId, runnable);
      continue;
    }

    // Skip if content is still an !inline reference (should have been replaced by replaceInlineScripts)
    if (typeof content === "string" && content.startsWith("!inline ")) {
      log.warn(
        colors.yellow(
          `Runnable ${runnableId} content is still an !inline reference, skipping`
        )
      );
      writeRunnableToBackend(runnablesFolder, runnableId, runnable);
      continue;
    }

    // Skip frontend scripts - they don't need locks
    if (language === "frontend") {
      // Still need to write the runnable YAML file
      // Use runnableId (the dict key) for file naming, consistent with
      // extractInlineScriptsForApps in sync.ts which also uses the key.
      // Using runnable.name would create duplicate files when name != key.
      const [basePathO, ext] = pathAssigner.assignPath(
        runnableId,
        language
      );

View on GitHub (pinned to e474e8803c)