Skip to content

fix(auth): use a local ServeMux and shut the callback server down cleanly#52

Open
SAY-5 wants to merge 1 commit into
flagship-io:mainfrom
SAY-5:fix/initiate-browser-auth-defmux-panic-51
Open

fix(auth): use a local ServeMux and shut the callback server down cleanly#52
SAY-5 wants to merge 1 commit into
flagship-io:mainfrom
SAY-5:fix/initiate-browser-auth-defmux-panic-51

Conversation

@SAY-5
Copy link
Copy Markdown

@SAY-5 SAY-5 commented Apr 23, 2026

Fixes #51.

Problem

InitiateBrowserAuth (internal/utils/http_request/common/token.go) had three issues:

  1. Registered /auth/callback on http.DefaultServeMux via http.HandleFunc, so any second invocation in the same process (re-login, tests, library use) panicked with http: multiple registrations for /auth/callback.
  2. The HTTP server was never proactively shut down after the callback arrived, it kept running until the 5-minute timeout fired, leaking a goroutine and a port binding.
  3. log.Fatalf was called from goroutines on non-fatal conditions (http.ErrServerClosed is the normal Shutdown return), which could kill the whole process unexpectedly.

Fix

  • Build a per-call http.ServeMux and register the handler on it.
  • Defer server.Shutdown with a 2-second timeout so the listener is reaped on return, regardless of which select branch fires.
  • Treat http.ErrServerClosed as the expected normal shutdown signal; use log.Printf for the actual error path.
  • The 5-minute timeout becomes an ordinary select branch and returns a clear "authentication timed out" error.

Test

go build ./internal/utils/http_request/common/... clean. (Repo-wide build has pre-existing errors in cmd/feature-experimentation/analyze/code-samples/vwo/go/sample-VWO.go that are unrelated to this change.)

…anly

InitiateBrowserAuth registered the /auth/callback handler on
http.DefaultServeMux via http.HandleFunc. Any second call in the same
process (re-login, tests, library use) panicked with 'http: multiple
registrations for /auth/callback'. The server was also never
proactively shut down, leaking a goroutine + port binding until the
5-minute timeout fired, and log.Fatalf was called from both
goroutines on conditions that aren't fatal (server.ErrServerClosed is
the normal Shutdown return).

- Build a per-call http.ServeMux and register the handler on it so
  repeat calls never collide with each other or with other handlers
  anyone else has on DefaultServeMux.
- Replace log.Fatalf with log.Printf on non-fatal conditions and
  treat http.ErrServerClosed as the expected normal shutdown signal.
- Defer server.Shutdown with a 2s timeout so the listener is reaped
  as soon as InitiateBrowserAuth returns, regardless of which
  select branch fires.
- Give the 5-minute timeout its own select branch so it returns a
  clear 'authentication timed out' error instead of leaking.

Refs flagship-io/abtasty-cli issue 51.

Signed-off-by: SAY-5 <say.apm35@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

auth login: panic on repeated invocation due to http.DefaultServeMux registration

1 participant