fix: relock go steps whose stored lock is not a go.mod

[rubenfiszel]

Fixes WIN-2141

Summary

A Go script or flow step whose stored lockfile is not actually a go.mod fails at runtime with:

exit code for "go tidy": 1
go: errors parsing go.mod:
go.mod:1: unknown directive: {
go.mod:2:3: unknown directive: "dependencies"
go.mod:3: unknown directive: }

That content is exactly bun's no-dependencies package.json — a lock left over from the step's previous language (e.g. a flow step created as TypeScript, later switched to Go). Two compounding causes:

1. Deploy: the flow/app dependency job keeps any non-empty existing lock (skip_creating_new_lock only special-cases bun↔bunnative), so the stale cross-language lock survives redeploys.
2. Runtime: handle_go_job writes the stored lock verbatim into go.mod and runs go mod tidy, which explodes on non-go.mod content.

The reported "single import fails, parenthesized import works, then single import works again" was sequencing, not parsing (parse_go_imports handles single-line imports fine — verified): any content edit clears the module lock in the editor and forces a proper relock, and the follow-up relock is served from pip_resolution_cache (both import styles hash to the same empty-imports key), which is the "like it was using some cached version" observation.

Changes

• go_executor.rs: new is_go_mod_lock helper — a usable Go lock always embeds a go.mod, which requires a module directive (token-based check, immune to JSON keys like "module": "esnext"). Unit tests included.
• go_executor.rs (handle_go_job): a Resolved lock that fails the check is ignored — a warning is appended to the job logs and the job falls back to MaybeLock::Unresolved, resolving dependencies from imports. This self-heals already-deployed scripts/flows carrying a bad lock, without redeploy. Placed before the binary-cache hash so the cache key reflects the regenerated resolution.
• worker_lockfiles.rs (skip_creating_new_lock, used by flow and app dependency jobs): a Go step whose existing lock is not a plausible go.mod is relocked instead of keeping the stale lock, repairing the stored flow/app value at deploy time.

Test plan

• cargo test -p windmill-worker --lib is_go_mod_lock passes
• Exact repro before fix: flow with a Go rawscript step carrying lock {"dependencies": {}} → dep job kept the JSON lock → run failed byte-for-byte with the reported go tidy / unknown directive: { error
• Dep-job fix: redeploying the same flow regenerates the lock (module mymod + //go.sum) and the flow runs successfully
• Runtime self-heal: Go script created with a bad JSON lock (dep job skipped) runs successfully; job log shows stored lockfile is not a go.mod (likely generated for another language), ignoring it and resolving dependencies from imports
• Healthy paths unaffected: fresh single-line-import Go script deploy + run, and preview run, both succeed

🤖 Generated with Claude Code

---

Summary by cubic

Fixes WIN-2141. Prevents Go steps from failing when a stale non-go.mod lock (e.g., a package.json) is stored by relocking on deploy and ignoring the bad lock at runtime.

• Bug Fixes
  • Added is_go_mod_lock to validate Go locks by checking for a module directive (with tests).
  • Runtime: handle_go_job now ignores a stored lock that isn’t a valid go.mod, logs a warning, and resolves deps from imports; cache key reflects the regenerated resolution.
  • Deploy: skip_creating_new_lock now relocks Go steps when the existing lock isn’t a valid go.mod, fixing stored locks during flow/app deploys.

^{Written for commit 78388d4. Summary will update on new commits.}

[cloudflare-workers-and-pages]

Deploying windmill with    Cloudflare Pages

Latest commit:	78388d4
Status:	✅  Deploy successful!
Preview URL:	https://c0b90b3c.windmill.pages.dev
Branch Preview URL:	https://ruben-win-2141-fix-go-single.windmill.pages.dev

View logs