Windows: fatal stack overflow (infinite recursion in kustomize kyaml fsnode path lookup) on any reconcile-running command

[nberk2]

Version / platform

flate 0.4.10, flate_0.4.10_windows_amd64.zip release binary, Windows 11 (PowerShell 7). The same repo renders fine with ghcr.io/home-operations/flate:0.4.10 under Docker Desktop on the same machine.

Symptom

Running any reconcile-running command natively on Windows against a Flux GitOps repo (e.g. flate test all --path clusters/prod) crashes ~1.5s in:

runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

The recursing frames alternate between kustomize kyaml's in-memory filesystem lookup and Go's Windows path helpers, with a 2-character path argument (which smells like a drive-letter volume name, e.g. C:):

internal/filepathlite.volumeNameLen({0x..., 0x2})
	internal/filepathlite/path_windows.go:206
internal/filepathlite.VolumeName({0x..., 0x2})
internal/filepathlite.Split({0x..., 0x2})
path/filepath.Split(...)
sigs.k8s.io/kustomize/kyaml/filesys.mySplit(...)
	sigs.k8s.io/kustomize/kyaml@v0.21.1/filesys/fsnode.go:103
sigs.k8s.io/kustomize/kyaml/filesys.(*fsNode).findIt(...)
	sigs.k8s.io/kustomize/kyaml@v0.21.1/filesys/fsnode.go:286
(repeats until stack exhaustion)

Looks like fsNode's parent-walk never terminates when the path reduces to a Windows volume name (C:), since Split(\"C:\") returns \"C:\" as the dir component again.

Repro

1. Windows host, extract the windows_amd64 release binary.
2. Any Flux repo: flate test all --path clusters/<cluster> (also crashes on build/diff).

Happy to provide the full stack dump or test patches. Thanks for flate - the Linux container path has been excellent (whole-cluster test all in ~3s).

[buroa]

Confirmed, and your read on the recursion is right - it bottoms out on a bare Windows volume name (C:), where kyaml's fsNode split keeps returning C: and never terminates.

The recursion itself is upstream in sigs.k8s.io/kustomize/kyaml, but it's only reachable because flate feeds absolute C:-prefixed paths into the in-memory layer of its overlay filesystem. That in-memory layer sits behind flate's own overlayFS and is populated exclusively by flate-authored paths, so we can normalize/guard at that boundary without waiting for an upstream release. Plan: guard the memory-layer probe for Windows volume-name paths (return the on-disk result directly, since the memory layer never holds a bare-volume prefix), with a test in the overlay fs suite. Appreciate the offer of the full dump - will ping if I need it to verify on Windows.