Engine panic in v0.19.11 (`unknown type`) | Dagger | Page 1

fathom trench Feb 9, 2026, 4:06 PM

#

I thought I'd raise this here as well. I still have the engine container lying around, in case there's any other info I can provide. (EDIT: nvm, the container was removed somehow?)

When refactoring a dagger module, I hit a snag calling dagger functions, where the cli logs this

✘ load module: . 2.2s ERROR
✘ initializing module 0.3s ERROR
! Post "http://dagger/query": command [docker exec -i dagger-engine-v0.19.11 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=

Issue: https://github.com/dagger/dagger/issues/11825

GitHub

🐞 Engine panics with `unknown type` (`GetOrInitializeWithCallbac...

What is the issue? I'm not certain how to this occurred, but I wanted to record the error here. I was refactoring an existing module, moving/deleting code (a Release struct) from one module (mo...

#

And the engine panics with this

a20a0e field=ModuleSource.asModule digest=xxh3:ef55b6ce06e7e1be
panic: unknown type: Release

goroutine 9727 [running]:
github.com/dagger/dagger/dagql/introspection.WrapTypeFromType(...)
    /app/dagql/introspection/types.go:557
github.com/dagger/dagger/dagql/introspection.(*Type).OfType(0x40044dd308)
    /app/dagql/introspection/types.go:724 +0x260
github.com/dagger/dagger/core/schema.dagqlToCodegenTypeRef(0x40044dd308)
    /app/core/schema/query.go:335 +0xe8
github.com/dagger/dagger/core/schema.dagqlToCodegenField(0x4004204360)
    /app/core/schema/query.go:263 +0x80
github.com/dagger/dagger/core/schema.dagqlToCodegenType(0x40059ceb40)
    /app/core/schema/query.go:191 +0x188
github.com/dagger/dagger/core/schema.getSchemaJSON({0x40034a6940, 0x1, 0x2b9bd00?}, {0x4000a40e70, 0x7}, 0x4007a59ce8?)
    /app/core/schema/query.go:102 +0xf0
github.com/dagger/dagger/core/schema.(*querySchema).schemaJSONFile(0x40043fb808, {0x381a730, 0x4004486c80}, {{0x0, 0x4000a804b0, 0x0, 0x0}, {0x0, 0x0, 0x4007f71560, ...}}, ...)
    /app/core/schema/query.go:147 +0x220
github.com/dagger/dagger/dagql.NodeFuncWithCacheKey[...].func1({{0x0, 0x4000a804b0, 0x0, 0x0}, {0x0, 0x0, 0x4007f71560, 0x4007f62c68, 0x4008048ad0}}, 0x4004decf30, ...)
    /app/dagql/objects.go:930 +0x12c
github.com/dagger/dagger/dagql.Class[...].Call(0x389afc0, {0x381a730, 0x4004486c80}, 0x4005586678?, {{0x0, 0x4000a804b0, 0x0, 0x0}, {0x0, 0x0, ...}}, ...)
    /app/dagql/objects.go:302 +0xa8
github.com/dagger/dagger/dagql.ObjectResult[...].call.func2()
    /app/dagql/objects.go:763 +0x90
github.com/dagger/dagger/engine/cache.(*cache[...]).GetOrInitializeWithCallbacks.func3()
    /app/engine/cache/cache.go:496 +0x58
created by github.com/dagger/dagger/engine/cache.(*cache[...]).GetOrInitializeWithCallbacks in goroutine 4065
    /app/engine/cache/cache.go:494 +0x10d0

minor rapids Feb 9, 2026, 5:24 PM

#

@queen trellis is looking into this, thanks for the report!

queen trellis Feb 9, 2026, 6:08 PM

#

are you able to share what the Release struct looks like, and how it's used by the functions (e.g. is it passed as an arg, or returned?)

fathom trench Feb 9, 2026, 7:13 PM

#

@queen trellis It was the module's root struct. I created a new module called release, copied the contents of a prior module's release functions to that new module, and renamed all functions to use it instead). The Release struct itself is empty, for example the module looked like:

type Release struct {}

func (m *Release) Start(...) { ... }
func (m *Release) Update(...) { ... }
func (m *Release) Complete(...) { ... }
func (m *Release) Deploy(...) { ... }

queen trellis Feb 9, 2026, 7:18 PM

#

what did the dagger.json look like for both modules -- was the name field set to "release" in both directories?

fathom trench Feb 9, 2026, 7:24 PM

#

Let me take a look here.. (some fields sanitized)

Module A (code moved from)

{
  "name": "codepipelines",
  "engineVersion": "v0.19.8",
  "sdk": {
    "source": "go"
  },
  "dependencies": [
    {
      "name": "docker",
      "source": "../../.dagger-modules/docker"
    },
    {
      "name": "github",
      "source": "private-daggerverse/daggerverse/github@main",
      "pin": "323c2cd756c82d35152404b0c09b8ebf5bff9823"
    },
    {
      "name": "notify",
      "source": "private-daggerverse/notify@main",
      "pin": "323c2cd756c82d35152404b0c09b8ebf5bff9823"
    },
    {
      "name": "repo-root",
      "source": "../.."
    }
  ],
  "disableDefaultFunctionCaching": true
}

Module B (new release module)

{
  "name": "release",
  "engineVersion": "v0.19.8",
  "sdk": {
    "source": "go"
  },
  "dependencies": [
    {
      "name": "github",
      "source": "private-daggerverse/github@main",
      "pin": "7c481e05b694871fa9c21b4818d6386be2e60e73"
    },
    {
      "name": "notify",
      "source": "private-daggerverse/notify@main",
      "pin": "7c481e05b694871fa9c21b4818d6386be2e60e73"
    }
  ]
}

queen trellis Feb 9, 2026, 7:27 PM

#

ok and the error then happened when you went back to run on module A, where the top level struct was called something like Codepipelines?

fathom trench Feb 9, 2026, 7:37 PM

#

That sounds about right. It was similar to:

Create release module
Copy code from codepipeline to release
Rename references of Codepipeline to Release
Tidy up imports
Call dagger functions in both directories

I'm realizing the type Release did not exist in module A, only in the new release module (module B). I must have invoked this on the new module to cause the error?

queen trellis Feb 9, 2026, 7:39 PM

#

I'm realizing the type Release did not exist in module A,
interesting! Yeah this is the part that was confusing me -- it seems very strange that the error in the panic references Release which never existed in the module.

#

I must have invoked this on the new module to cause the error?
it could be possible that there's something really odd with the caching keys dagger is using (which would result in modules A and B sharing/referencing/misusing the same cache)..... but I'm trying to figure that out 😅

fathom trench Feb 9, 2026, 7:43 PM

#

Yeah, sorry about that. I was bouncing back and forth between the two directories and might have misinterpreted the output

Thanks for looking into this 🙂

fathom trench Feb 9, 2026, 8:19 PM

#

Okay. I have some follow-up pieces

I can reproduce this consistently using a fresh dagger v0.19.11 engine
This occurs when calling the old module (module A, in our above examples) not the release module

These are the only occurrences of release/Release in module A:

$ rg -i "release" .codepipeline/app
.codepipeline/app/main.go
46:// or "release candidate" branch.
47:// Example: release-candidate-2025-04-22
48:var rcBranchExpr = regexp.MustCompile(`^release-candidate-\d{4}-\d{2}-\d{2}$`)
81:        tag:       "release_candidate",
87:        tag:       "release",
304:                    return nil, errors.New("source git repository contain any release candidate branches")
315:                srcTag = "release_candidate"

This is the directory structure for the dagger modules

.
├── .codepipeline/
│   └── app
│       └── dagger.json
├── .dagger/
├── .dagger-modules/
│   └── release
│       └── dagger.json
└── dagger.json

#

Commenting out different dependencies, I've arrived at the repo-root/app being a problematic dependency. If I remove this dependency:

    {
      "name": "repo-root",
      "source": "../.."
    }

from the module A's dagger.json the module compiles... Again, there are no instances of release/Release in the repo's .dagger/ directory

$ rg -i "Release" .dagger

Ah, this might be a circular (edit: not circular) dependency? I have the release module installed as a toolchain in app's dagger module.

#

@queen trellis I think I have a concrete example now: the codepipeline module depends on app, which depends on release (as a toolchain). This is where the Release type is coming from (afaict)

queen trellis Feb 9, 2026, 8:38 PM

#

ah interesting! thanks for deeper dive.

queen trellis Feb 9, 2026, 9:02 PM

#

woohoo, I got the panic on my end!

queen trellis Feb 11, 2026, 1:00 AM

#

I'm still trying to walk through why this is happening -- it seems like the both the repo-root and the referenced toolchain get installed into different dagql.Server instances; then when the schema is looked up on the repo-root, it can't find the toolchain because it's not looking on the correct dagql.Server instance.

I have a feel this issue has existed for some time now -- e.g. I was able to reproduce it under v0.19.5

minor rapids Feb 11, 2026, 1:03 AM

#

queen trellis I'm still trying to walk through why this is happening -- it seems like the both...

ok good to know it's not new! cc @fiery onyx not sure to what extent if at all it's related to https://github.com/dagger/dagger/pull/11753

@queen trellis maybe for now we could just do a quick fix so this is an error rather than panic, don't need to address the root cause immediately

queen trellis Feb 11, 2026, 1:12 AM

#

minor rapids ok good to know it's not new! cc <@135620352201064448> not sure to what extent i...

I was hoping to get to the bottom of it, since changing the return types to include an error seemed like a pain, since there's a few places that set field structs, e.g. https://github.com/dagger/dagger/blob/bbd67ba4796e0dde3607e534afaf5eec83a14ec1/dagql/introspection/types.go#L346

but I might have to give that a try since the fix doesn't seem obvious.

minor rapids Feb 11, 2026, 1:13 AM

#

queen trellis I was hoping to get to the bottom of it, since changing the return types to incl...

Yeah it may not be worth the effort to get to the bottom of as we are changing a bunch of stuff inthe toolchain area soon. But preventing panic's is always worth it 😄

#Engine panic in v0.19.11 (`unknown type`)