#Dagger hides details of exec failures when module syncs return value of other module

1 messages · Page 1 of 1 (latest)

quaint kernel
#

This trace is useless: https://dagger.cloud/Max/traces/bb9003c5186a442bdc340936db5a6a63

Or, at least, it's less useful than it should be.

The path of failure is:

dagger call -m sdk/dotnet/dev publish-thunk ...
  sdk/dotnet/bootstrap.ModuleRuntime(...)
    ... details omitted, succeeds
  .withExec()
    process inside container: /usr/bin/dotnet /Thunk/Dagger.Thunk.dll
      dotnet function: Dagger.Thunk.Main()
        functionCall = dag.CurrentFunctionCall()
        parentName = functionCall.ParentName() -> "DotnetSdkDev"
        dotnet function: Dagger.Thunk.Invocation.Run(functionCall, parentName "DotnetSdkDev", moduleName "DotnetSdkDev")
          functionName = functionCall.Name() -> "PublishThunk"
          arguments = functionCall.InputArgs()
          dotnet function: Dagger.DotnetSdkDev.PublishThunk(arguments)
            thunkContainer = sdk/dotnet/bootstrap.Thunk()
              dagger engine implementation details
                golang function: sdk/dotnet/bootstrap.Thunk(source Directory)
                  codegened = dag.Directory().WithDirectory(...).AsModuleSource(...).GeneratedContextDirectory()
                    dagger engine implementation details
                      golang function: sdk/dotnet/bootstrap.Codegen(...)
                        build = dag.Container()...WithExec(["foo", "bar"]).Directory("/Out") <- THIS WITHEXEC FAILS
                        temporary code I put in syncs the WithExec step with expect-any
                          panics with its stderr & stdout if return code non-zero <- THIS HAPPENS (DOESN'T SEEM TO MATTER)
                  return dag.Container()...WithDirectory(..., codegened)
            return dag.Container()...WithDirectory("/", thunkContainer.Directory(...))...WithExec(...).Stdout()

The trace just shows this:

dagger call ...
  sdk/dotnet/bootstrap.ModuleRuntime(...)
    ... trace shows these details
  .publishThunk(...)
    upload ...
      filesync
        copy

...

quaint kernel
#

In short, CLI calls dotnet module function calls Golang module function calls Golang module function which panics. Trace omits the fact that Golang module function was ever called.

The dotnet function that is invoked by the CLI (dev.PublishThunk()) syncs a Container, so it does a GraphQL query to "solve" an ID for the return value of the call to dependency module function sdk/dotnet/bootstrap.Thunk() which fails because it panics. The Dotnet SDK's GraphQL query implementation details receive the following light-on-details response from Dagger Engine:

ResponseHeaders:
    [0]:
        Date:
            [0]: Sun, 04 May 2025 21:27:41 GMT
StatusCode: OK
Data: null
Errors:
    [0]:
        Locations: null
        Message: failed to run codegen: failed to generate code: failed to call sdk module codegen: select: process "/runtime" did not complete successfully: exit code: 2
        Path:
            [0]: bootstrap
            [1]: thunk
        Extensions: null
Extensions: null

I don't see how any of the dotnet implementation details could be responsible for the omission. The Dotnet SDK sends a GraphQL request which requires calling a golang function. The golang function gets called, runs its own query invoking another golang function, which also gets called. We have Dagger golang module functions being called but not included in the trace.

Manually making the same call that the first module-function, dagger call -m sdk/dotnet/bootstrap thunk, reveals more details, including the stdout of the failing golang program execution. Disappoingingly, it still omits the fact that withExec(command that fails) was ever called. The only way I could retrieve the failing command's stdout was to modify the golang function to sync it permissibly and then log or return the stdout.

#

I'm on 0.16.3 right now because I'm trying to automate new version publishing for this SDK before upgrading to the latest engine. So, my questions are:

  • Is this known and fixed already in a newer version?
  • If not, is there anything I'm doing wrong?