windmill-labs/windmill · warning

ws_specific_flag change for unsupported kind '${change.kind}

Error message

ws_specific_flag change for unsupported kind '${change.kind}' at ${change.path} — skipping

What it means

When applying ws_specific (workspace-specific flag) changes during `wmill sync push`, the CLI only knows how to update ws_specific for supported resource kinds (e.g. variables, via wmill.updateVariable). If a change with kind not supported for ws_specific arrives, it logs this warning and skips it instead of failing the push.

Source

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

                  // state target may not exist already
                }
              }
            } else if (change.name === "ws_specific_flag") {
              const target = change.path.replaceAll(SEP, "/");
              if (change.kind === "resource") {
                await wmill.updateResource({
                  workspace: workspace.workspaceId,
                  path: removeType(target, "resource"),
                  requestBody: { ws_specific: change.wsSpecific },
                });
              } else if (change.kind === "variable") {
                await wmill.updateVariable({
                  workspace: workspace.workspaceId,
                  path: removeType(target, "variable"),
                  requestBody: { ws_specific: change.wsSpecific },
                });
              } else {
                log.warn(
                  `ws_specific_flag change for unsupported kind '${change.kind}' at ${change.path} — skipping`,
                );
              }
            }
          }
        })();

        pool.add(promise);
        // Remove from pool when complete
        promise.then(() => {
          pool.delete(promise);
          if (isFolderGroup) folderPhaseRemaining--;
        });
      }

      // Wait for at least one task to complete before continuing
      if (pool.size > 0) {
        await Promise.race(pool);

View on GitHub (pinned to e474e8803c)

Solutions

1. Inspect the change at the reported path and remove the ws_specific field for that kind if it's not meaningful.
2. Update the CLI to the latest version so new kinds with ws_specific support are handled.
3. If ws_specific is intended for that kind, file/verify support exists in wmill.yaml spec — only variables (and specific kinds) support it today.

Example fix

// Remove unsupported ws_specific from the file's metadata
// before
// (file with kind: script carries ws_specific in its metadata)
// after
// delete the ws_specific key from the file metadata, or move it to a variable:
wmill variable set myvar/ws_specific_value

// Only set ws_specific on supported kinds (variables):
if (metadata.wsSpecific !== undefined && kind !== 'variable') {
  delete metadata.wsSpecific;
}

function supportsWsSpecific(kind: string): boolean {
  return kind === 'variable';
}

When it happens

Trigger: A change entry in the push plan has a wsSpecific value set but its `kind` is not variable (or another supported kind) — usually produced by an unexpected file type in the sync folder or a CLI/server version mismatch introducing new kinds.

Common situations: Hand-placed files in sync folders that map to kinds without ws_specific support; newer server emitting kinds the local CLI doesn't handle; script-generated change sets.

Related errors

• Workspace folder not found, are you in the right directory?
• Not a fileset resource path: ${changePath}
• No resource metadata file found for fileset resource: ${chan
• Found ${wrongFormatPaths.length} directory(ies) using ${foun
• pointerErrors.join("\n")

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