docker/compose · error

loading otel config from docker context metadata: %w

Error message

loading otel config from docker context metadata: %w

What it means

When initializing tracing, compose reads the active Docker CLI context's metadata to find an embedded OTLP config (Docker Desktop integration). If st.GetMetadata(name) fails — context not found, unreadable context store, corrupt metadata file — the client setup aborts with 'loading otel config from docker context metadata: %w'. Per InitProvider, this error is joined and returned, failing tracing init.

Source

Thrown at internal/tracing/docker_context.go:42

	"github.com/docker/cli/cli/context/store"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
	"google.golang.org/grpc"
	"google.golang.org/grpc/credentials/insecure"

	"github.com/docker/compose/v5/internal/memnet"
)

const otelConfigFieldName = "otel"

// traceClientFromDockerContext creates a gRPC OTLP client based on metadata
// from the active Docker CLI context.
func traceClientFromDockerContext(dockerCli command.Cli, otelEnv envMap) (otlptrace.Client, error) {
	// attempt to extract an OTEL config from the Docker context to enable
	// automatic integration with Docker Desktop;
	cfg, err := ConfigFromDockerContext(dockerCli.ContextStore(), dockerCli.CurrentContext())
	if err != nil {
		return nil, fmt.Errorf("loading otel config from docker context metadata: %w", err)
	}

	if cfg.Endpoint == "" {
		return nil, nil
	}

	// HACK: unfortunately _all_ public OTEL initialization functions
	// 	implicitly read from the OS env, so temporarily unset them all and
	// 	restore afterwards
	defer func() {
		for k, v := range otelEnv {
			if err := os.Setenv(k, v); err != nil {
				panic(fmt.Errorf("restoring env for %q: %w", k, err))
			}
		}
	}()
	for k := range otelEnv {
		if err := os.Unsetenv(k); err != nil {

View on GitHub (pinned to ddc4b044b6)

Solutions

  1. List and prune contexts: docker context ls, docker context rm <broken>, docker context use <valid>
  2. Recreate the default context: docker context create default --docker host=unix:///var/run/docker.sock (or just remove the stale DOCKER_CONTEXT env var)
  3. Verify the store files parse: cat ~/.docker/contexts/meta/*/meta.json | jq . — repair or delete corrupt entries
  4. If DOCKER_CONFIG is set, ensure it points at a directory containing a valid context store

Example fix

# before: stale context referenced
export DOCKER_CONTEXT=removed-ctx
# after: use a real one / unset
unset DOCKER_CONTEXT
docker context use default
Defensive patterns

Strategy: validation

Validate before calling

// verify the context resolves before initializing tracing
if _, err := dockerCli.ContextStore().GetMetadata(dockerCli.CurrentContext()); err != nil {
    // fall back: skip context-based tracing or fix context first
}

Try / catch

// catch the wrap from InitTracing; on context-store errors, switch context (docker context use default) or tolerate degraded tracing and continue

Prevention

When it happens

Trigger: InitTracing/InitProvider running while dockerCli.CurrentContext() names a context that does not exist in the context store, or ~/.docker/contexts/meta/<hash>/meta.json is corrupt/unreadable/deleted mid-run.

Common situations: DOCKER_HOST or DOCKER_CONTEXT pointing at a removed context; a partially deleted or hand-edited context store; DOCKER_CONFIG redirected to a directory without context metadata; Docker Desktop context entries damaged by an upgrade.

Related errors


AI-assisted analysis of docker/compose@ddc4b044b6 (2026-08-15). Data as JSON: /api/errors/440654d55a7ff410. Report an issue: GitHub.