derailed/k9s · error

no application found in context

Error message

no application found in context

What it means

Returned by `extractApp` (internal/view/helpers.go:~174) when the context passed to a view helper does not carry the application under `internal.KeyApp` (string key "app"), or the stored value is not a `*view.App`. The App injects itself in its context function (internal/view/app.go:98: `context.WithValue(ctx, internal.KeyApp, a)`); helpers like browser/describe commands then pull it back out. A bare context (context.Background(), or one built without the app's ContextFn) fails the type assertion.

Source

Thrown at internal/view/helpers.go:174

	if err := app.Config.SetActiveNamespace(ns); err != nil {
		slog.Error("Unable to set active namespace during show pods", slogs.Error, err)
	}
	if err := app.inject(v, false); err != nil {
		app.Flash().Err(err)
	}
}

func podCtx(_ *App, path, fieldSel string) ContextFunc {
	return func(ctx context.Context) context.Context {
		ctx = context.WithValue(ctx, internal.KeyPath, path)
		return context.WithValue(ctx, internal.KeyFields, fieldSel)
	}
}

func extractApp(ctx context.Context) (*App, error) {
	app, ok := ctx.Value(internal.KeyApp).(*App)
	if !ok {
		return nil, errors.New("no application found in context")
	}

	return app, nil
}

// AsKey maps a string representation of a key to a tcell key.
func asKey(key string) (tcell.Key, error) {
	for k, v := range tcell.KeyNames {
		if key == v {
			return k, nil
		}
	}

	return 0, fmt.Errorf("invalid key specified: %q", key)
}

// FwFQN returns a fully qualified ns/name:container id.
func fwFQN(po, co string) string {

View on GitHub (pinned to 2d3ccc6ba2)

Solutions

  1. Build the context through the app/view's ContextFn so KeyApp is populated before invoking helpers
  2. If calling manually: `ctx = context.WithValue(ctx, internal.KeyApp, app)` with the canonical *view.App instance
  3. In tests, inject a real NewApp(cfg) value under internal.KeyApp (see helpers_test.go pattern)
  4. Pass the App explicitly instead of via context when you control the call sites

Example fix

// before
ctx := context.Background()
app, err := extractApp(ctx) // -> no application found in context
// after
ctx := context.WithValue(context.Background(), internal.KeyApp, myApp)
app, err := extractApp(ctx)
Defensive patterns

Strategy: type-guard

Validate before calling

// Build contexts only through the app's ContextFn so KeyApp is set:
ctx = context.WithValue(ctx, internal.KeyApp, app)

Type guard

func appFromCtx(ctx context.Context) (*App, bool) {
    app, ok := ctx.Value(internal.KeyApp).(*App)
    return app, ok
}

Try / catch

app, err := extractApp(ctx)
if err != nil {
    slog.Error("missing app in context", slogs.Error, err)
    return
}

Prevention

When it happens

Trigger: Calling a helper that uses extractApp with a context that was not produced by the app's context function — e.g. plugins or custom views passing context.Background(), or a context built with a different ContextKey/value type.

Common situations: Custom k9s forks/plugins invoking internal/view helpers directly; tests calling helpers without injecting KeyApp; refactors that bypass SetContextFn.

Related errors


AI-assisted analysis of derailed/k9s@2d3ccc6ba2 (2026-08-15). Data as JSON: /api/errors/163200cd15c18187. Report an issue: GitHub.