Skip to content

feat(landing): capability-driven default landing route per active box - #133

Merged
sarg3nt merged 1 commit into
fix/issue-112-haproxy-empty-statefrom
fix/issue-112-default-landing-route
May 17, 2026
Merged

feat(landing): capability-driven default landing route per active box#133
sarg3nt merged 1 commit into
fix/issue-112-haproxy-empty-statefrom
fix/issue-112-default-landing-route

Conversation

@sarg3nt

@sarg3nt sarg3nt commented May 17, 2026

Copy link
Copy Markdown
Owner

Summary

  • RootRedirect's fallback chain hard-coded /haproxy for any install with ≥1 enabled box. On a TrueNAS-style deployment whose agent runs in a distroless container without HAProxy (Mjolnir), this dropped users on an empty /haproxy page that 503-storms on the per-box stat tiles.
  • New Handler.defaultLandingForActiveBox(r) helper picks the landing path from the active box's probe table: haproxy → metrics → bx, with /haproxy as the fail-open default when capabilities are unreachable.
  • Per-user / system landing-path overrides (resolvePostLoginPath) still win — a user who has explicitly set their landing URL keeps it.

Phase 2 slice of #112. Stacked on #118 (which is stacked on #115); merge those first, then this.

Test plan

  • go build ./..., go vet ./... clean
  • go test -count=1 -run TestDefaultLandingForActiveBox ./internal/framework/handler/... — 4 tests, all green (haproxy-capable, metrics-only, bx-fallback, agent-down fail-open)
  • On a deployment where Mjolnir is the active box: log in to gearbox, confirm landing on /metrics rather than /haproxy.
  • On a deployment where light-hugger is the active box: log in, confirm landing on /haproxy (no regression).
  • Stop the active box's agent, log in: confirm landing on /haproxy (fail-open).

🤖 Generated with Claude Code

…#112)

RootRedirect's fallback chain hard-coded /haproxy as the dashboard
default for any installation with at least one enabled box. On a
TrueNAS-style deployment whose agent runs in a distroless container
without HAProxy (Mjolnir), users would log in and be dropped on an
empty /haproxy page that 503-storms on the per-box stat tiles.

Make the landing route per-box and capability-aware:

  - /haproxy when the active box's agent reports haproxy available
    (preserves the historical landing for HAProxy-fronted deployments)
  - /metrics when haproxy isn't available but metrics is — the
    next-most-useful single-pane-of-glass for a host-only agent
  - /bx as the universal fallback so an active box with no advertised
    gears still has a place to land

Fail-open to /haproxy when capabilities can't be fetched (agent down,
no API key, older agent that pre-dates probing) so a transient outage
doesn't change the dashboard's behavior.

Per-user / system landing-path overrides (login.go::resolvePostLoginPath)
keep priority over this — a user who has explicitly set their landing
URL still gets it.

Four tests exercise the new helper against a real httptest.Server
returning capability responses: haproxy-prefers-haproxy,
no-haproxy-falls-to-metrics, host-only-falls-to-bx, and
agent-down-fails-open-to-haproxy.

Phase 2 slice of #112. Stacked on fix/issue-112-haproxy-empty-state (#118).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@sarg3nt
sarg3nt merged commit 0836abe into fix/issue-112-haproxy-empty-state May 17, 2026
3 checks passed
@sarg3nt
sarg3nt deleted the fix/issue-112-default-landing-route branch May 17, 2026 19:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant