#`dagger mod sync` infinite loop
1 messages · Page 1 of 1 (latest)
fun! that should be interruptible now at least. are you able to press q?
dagger mod sync infinite loop
Nah, can't even ctrl+c it, terminal is locked. I can kill it from another session
hmm, when's the last time you pulled?
a few minutes ago
i ran into this yesterday, but pushed a supposed fix. couldn't confirm because i couldn't repro anymore
can i repro by just cloning your repo?
hopefully? I'm on dagger@6f12382, looks like that's still latest
trying now
doesn't happen for me
dagger mod sync from the golang subdirectory?
i guess make 100% sure the dagger in your $PATH is the one you expect?
does --focus=false reveal anything?
Checking now. Interesting and maybe related, I now have a bunch of goenv processes hammering my system
yeah interesting. it's probably running go mod tidy as it loops, but a) that should be synchronous, and b) why would it lead to that
got all those processes cleaned up and started a new dev engine
focus=false doesn't reveal much here
interesting, this looks like a different kind of hang
the one before was looping infinitely, so you'd see the vertex count growing
ah ok
try running with --progress=plain and sending SIGQUIT after a minute or so? (just to make it easier for me to see which goroutines are hard-stuck)
🙏 swirly time
the killed processes left a bunch of zombie goenv again
looks like it's getting stuck in golang.org/x/gools/go/packages.Load, which apparently shells out to go. Interestingly the goroutines don't say they've been stuck for a while, so I wonder if it's some kind of busy loop
could it be because i'm using goenv instead of a specific go version install?
worth eliminating that variable and seeing if it fixes it, definitely need to get it working however you have it set up though
for the sake of logging what i'm doing: i was on go 1.20, upgrading to 1.21 did not help
running into the same thing in my greetings-api project, so this is just my life now
does it unbreak if you go back to whatever version of Zenith you were using yesterday? 🤔
are you able to bootstrap a new module using the instructions from zenith/README.md?
reverting to e86435e0b does fix the sync
going back to latest to try bootstrapping
back on latest it looks like it's hanging on generation for a new module as well
any chance you've got the patience for a good old git bisect? looking through git log now...
~/src/dagger/zenith zenith-functions ≡ ⇡
❯ mkdir test
~/src/dagger/zenith zenith-functions ≡ ⇡
❯ cd test
~/src/dagger/zenith/test zenith-functions ≡ ⇡
❯ dagger mod init --name test --sdk go
WARNING: Using development engine; skipping version compatibility check.
WARNING: no main package or module found; falling back to bare module name
WARNING: already bootstrapped
• Engine: cd1b6f3f8aa4 (version devel ())
⧗ 0.88s ✔ 8
~/src/dagger/zenith/test zenith-functions ≡ ⇡
❯
I guess I'll try using goenv?
I guess one other thing to note is i'm still manually building the cli instead of getting it from ./hack/dev because ./hack/dev is still giving me that corrupted binary
oh, are you running ./hack/dev to build + update the engine though?
pushed a commit that I don't think will fix it, but might at least make it so you can quit out of it
worth a shot, just to confirm where it's getting stuck
oh, there's one more spot that might hang, but we'll see
pushed that too
cool, yeah it was still hanging
still locking up on the latest
i've just been running pkill -f '.*goenv.*' from another terminal to free it
I have a hunch, following up on it now..
tl;dr there were various places before that passed around paths like foo/config.json and used filepath.Dir(x) to get the parent. part of my refactor changed that to just foo/, but there might still be a filepath.Dir(x) usage somewhere, which would then point things to the module's parent directory, which i dunno might have thousands of Go modules/packages. (my kingdom for distinct file/dir path types!)
nice, yeah I haven't actually tried letting it go on forever
@cosmic portal pushed 🤞
still infinity
going to try real quick with a non-goenv setup to make sure that's the problem
yup regular go install fixes it 🤷 I'll stay on this for now, probably not worth worrying about today
since the dawn of time
