pine stump
Any idea?
Error: Post "http://dagger/query": command [docker exec -i dagger-engine-v0.19.8 buildctl dial-stdio] has exited with exit status 137, make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=
15:31:57 ERR cleanup failed msg="close dagger session" err="shutdown: do shutdown: Post \"http://dagger/shutdown\": http2: frame too large" duration=7m5.361270194s
snow kayak
Any idea?
```
Error: Post "http://dagger/query": command [docker exec -i dagger...
@pine stump seems like the Dagger engine failed to start for some reason. Running docker logs dagger-engine-v0.19.8 should reveal what the reason of the failure is
pine stump
Nah, it's running and lots of logs
[root@ip-10-3-16-196 lib]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b40eab5a19c4 registry.dagger.io/engine:v0.19.8 "dagger-entrypoint.s…" 14 minutes ago Up 13 minutes dagger-engine-v0.19.8
I have some time if you want to jump into a quick call to show me what's happening Roman. Does that work for you?
pine stump
sure
would be great
But this exact issue happened one time, now the issue from my other thread rpc error is happening and this one is not
snow kayak
But this exact issue happened one time, now the issue from my other thread rpc e...
ping me whenever we can check it together and happy to join a call Roman!
forest falcon
We just ran into this error, engine shows a panic:
panic: runtime error: index out of range [3] with length 3
goroutine 249244 [running]:
github.com/dagger/dagger/core.ContainerDagOp.CacheMap(...)
/app/core/dagop.go:552
github.com/dagger/dagger/engine/buildkit.(*CustomOpWrapper).CacheMap(0x79f1463a0018, {0x33fe298, 0x79f14de7f050}, {0x33c7ee0, 0x79f14cc10e60}, 0x79f153a83c00?)
/app/engine/buildkit/op.go:115 +0xb0
github.com/dagger/dagger/internal/buildkit/solver.(*sharedOp).CacheMap.func2({0x33fe2d0, 0x79f154067180})
/app/internal/buildkit/solver/jobs.go:907 +0x36c
github.com/dagger/dagger/internal/buildkit/util/flightcontrol.(*call[...]).run(0x342da60)
/app/internal/buildkit/util/flightcontrol/flightcontrol.go:139 +0x1b0
sync.(*Once).doSlow(0x0?, 0x79f14b017380?)
/usr/lib/go/src/sync/once.go:78 +0xdc
sync.(*Once).Do(...)
/usr/lib/go/src/sync/once.go:69
created by github.com/dagger/dagger/internal/buildkit/util/flightcontrol.(*call[...]).wait in goroutine 249240
/app/internal/buildkit/util/flightcontrol/flightcontrol.go:183 +0x544
@snow kayak If I remove my client side go parallelism, the panic is avoided. Did I miss a breaking cache change? I have 'disableDefaultFunctionCaching' set to true and am on 20.2
forest falcon
Found a workaround (switch all my WithMountedFile to WithFile for now) and I think I have root cause: When a container's DagOp has mounts whose input LLB states overlap with the function's arg deps, BuildKit deduplicates them during FileOp marshaling, reducing cm.Deps length below the mount.Input indices computed by getAllContainerMounts, causing an index-out-of-bounds panic in ContainerDagOp.CacheMap at dagop.go:552
snow kayak
We just ran into this error, engine shows a panic:
```
panic: runtime error: in...
looks like something that might be fixed once we remove the buildkit solver from the engine. cc @celest schooner and @runic fog