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
- Build the context through the app/view's ContextFn so KeyApp is populated before invoking helpers
- If calling manually: `ctx = context.WithValue(ctx, internal.KeyApp, app)` with the canonical *view.App instance
- In tests, inject a real NewApp(cfg) value under internal.KeyApp (see helpers_test.go pattern)
- 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
- Never pass context.Background() to view helpers
- Always use SetContextFn/ContextFn chain that injects KeyApp
- Prefer passing *App explicitly in new code
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
- expecting a TreeNode but got %T
- no benchmark dir found in context
- no path specified in context
- expecting context GVR
- expecting context Path
AI-assisted analysis of derailed/k9s@2d3ccc6ba2 (2026-08-15).
Data as JSON: /api/errors/163200cd15c18187.
Report an issue: GitHub.