#Error `Error Post http dagger query EOF`
1 messages · Page 1 of 1 (latest)
With new go 1.20 release our dagger pipelines started to fail and when we rollback go version to 1.19 everything returned normal. I tried to reproduce same error with new pipeline it didn't happend again.
go version go1.19.3 linux/amd64
› mage -v test:unit
Running target: Test:Unit
...
#1 DONE 0.1s
#2 copy / /
#2 DONE 0.3s
#3 copy /go.mod /
#3 CACHED
#4 copy /go.sum /
#4 CACHED
#5 resolve image config for docker.io/library/golang:1.19
#5 DONE 1.7s
#6 mkdir /meta
#6 DONE 0.1s
#7 docker-image://docker.io/library/golang:1.19
#7 resolve docker.io/library/golang:1.19
#7 resolve docker.io/library/golang:1.19 0.2s done
#7 DONE 0.4s
#7 docker-image://docker.io/library/golang:1.19```
This is a normal execution with 1.19
go version go1.20 linux/amd64
› mage -v test:unit
Running target: Test:Unit
...
#1 DONE 2.0s
#2 copy / /
#2 DONE 0.3s
#3 copy /go.mod /
#3 DONE 0.1s
#4 copy /go.sum /
#4 DONE 0.6s
Error: Post "http://dagger/query": EOF
Please visit https://dagger.io/help#go for troubleshooting guidance.```
Exact same code when we run with go 1.20
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1201e79b1f5 ghcr.io/dagger/engine:v0.3.7 "buildkitd --oci-wor…" About a minute ago Up About a minute dagger-engine-9ad18aca71b1b1ba```
it seems I didn't bump dagger version for the repo. I'll try to update dependencies latest version and try again

I forget to mention docker image version also same. Only bumped local go version
let me do a test really quick with Go 1.20
a very simple "hello world" program works in Go 1.20 and latest Dagger engine.. I'll try running our test suite
Bumping dagger engine to latest version fixed this issue. I didn't get same issue with ghcr.io/dagger/engine:v0.3.10
which version were you using before? Trying to repro
but I still wonder why we're getting this error. 1.20 shouldn't introduce any breaking changes as far as I can see.
let me check
I think another user has an issue related to this one. I thought it was windows stuff but this might be the root cause
dagger.io/dagger v0.4.2
I had another issue related with go 1.20 from a library we're using. This could be the similar dependency issue
we had panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.18 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.18 set. Notably, if go1.18 adds a moving garbage collector, this program is unsafe to use.
one of our dependencies was indirectly using go4.org/unsafe/assume-no-moving-gc in their code and this was causing panix
Just tried hello-world against 0.4.2 and seems to be running ok as well 🤔
Fake alert on my side, the other user had an unrelated issue
let me do the same with mesosphere/daggers as well, maybe it's something we're injecting
this user has the same issue @scarlet blade (https://discord.com/channels/707636530424053791/1070997951503151104). Also in v0.4.2
Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.
however, I couldn't repro with a simple example and 0.4.2
I just tried with our repo and didn't able to produce it again
Was the engine re-spawned in between ? The last time we had such error message was because of the state of the container engine (stopped for example). But since then, we added the fix to print the error messages
I tried multiple times with new engine or exisiting engine instances. Error was consistent for that project
but couldn't re-produce in other projects
I just rollback the fix in the repo and re-produce the error.
Do you have any hint to debug this error
@wanton burrow by rollback the fix what do you mean exactly?
the unsafe lib thing you mentioned above?
I'm just curious and returned to using dagger v0.4.2
trying to see what is break to app.
ok, I see so it happens on a single repo only?
yes, I'm able to reproduce the error because I forget to bump dependencies here
can you try go clean -cache and see if still happens?
interesting, it passed previous error point first but later it failed with same error.
But now again after cleaning everything including docker, error consistent
time="2023-02-03T16:10:49Z" level=debug msg="remove snapshot" key=a3pnf2678hnh2qw8fsy4dyuws snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="remove snapshot" key=ky13d6x635szkhqgvp2u076q9 snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="remove snapshot" key=m4ifraund99pseap731l6ubyw snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="remove snapshot" key=w5ogr03j22gzyqg5wzkg0fh35 snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="remove snapshot" key=x7qr5jqyi5jht905l8idi9vzd snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="schedule snapshotter cleanup" snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="removed snapshot" key=buildkit/26/m4ifraund99pseap731l6ubyw snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="removed snapshot" key=buildkit/31/ky13d6x635szkhqgvp2u076q9 snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="removed snapshot" key=buildkit/34/x7qr5jqyi5jht905l8idi9vzd snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="removed snapshot" key=buildkit/45/a3pnf2678hnh2qw8fsy4dyuws snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="removed snapshot" key=buildkit/41/w5ogr03j22gzyqg5wzkg0fh35 snapshotter=overlayfs
time="2023-02-03T16:10:49Z" level=debug msg="snapshot garbage collected" d=102.083581ms snapshotter=overlayfs
time="2023-02-03T16:10:50Z" level=error msg="/moby.buildkit.v1.frontend.LLBBridge/ReadFile returned error: rpc error: code = Canceled desc = context canceled\n"```
I runned couple this sequentially. It started to execute the tests and in the middle it failed again. This is the last logs from engine
strange that this is happening in go 1.20 only 🤔
anyway, at least it's solved by new version. If you want to look something I can recreate issue anytime
yes, it's pretty unstable in 1.20 for our workflow
I'll defer this to @old matrix since it seems to be happening in the internals of buildkit for some reason
sure, just let me know if you want to debug this again
I think those buildkit logs are just saying that the client closed its connection, which in this case is probably the dagger session binary. The stuff about snapshot removal and garbage collection are normal.
But yeah very strange, glad that the latest version fixes it somehow but still would love to know why
didn't deep dive the debugging but I saw biggest difference between 0.4.2 and 0.4.4 seems dependencies used in dagger. I think one of this dependencies is the issue.