Describe the bug
When Spotify authentication is required on startup (no valid cached token — e.g. first install, or an expired/invalidated cached token), the app prints Waiting for authorization callback on http://127.0.0.1:8989... and hangs forever. The browser opens and Spotify's consent screen works, but after approving, the redirect to http://127.0.0.1:8989/login?code=... shows "Unable to connect" — nothing is ever bound to that port (confirmed with ss -tlnp). The process doesn't crash; it just sits idle indefinitely.
Root cause: in src/core/auth.rs, ensure_auth_token is an async fn but calls the blocking redirect_uri_web_server(auth_port) (line 334) directly, with no spawn_blocking. That function uses std::net::TcpListener and blocks the tokio worker thread instead of yielding, so the listener never reliably reaches bind()/accept(). The file already has an async-safe version — redirect_uri_web_server_async (src/infra/redirect_uri.rs:90) — which is used for the in-TUI login flow but not for this startup path.
Fix (one line):
-use crate::infra::redirect_uri::redirect_uri_web_server;
+use crate::infra::redirect_uri::redirect_uri_web_server_async;
@@ ensure_auth_token @@
- match redirect_uri_web_server(auth_port) {
+ match redirect_uri_web_server_async(auth_port).await {To Reproduce
Steps to reproduce the behavior:
- Ensure no valid cached token exists (fresh install, or delete
~/.config/spotatui/streaming_cache/ and any cached token), so needs_auth is true.
- Launch
spotatui; it prints Waiting for authorization callback on http://127.0.0.1:8989... and opens the browser.
- Complete the Spotify consent screen and approve.
- Browser redirects to
http://127.0.0.1:8989/login?code=... → "Unable to connect". ss -tlnp shows nothing listening on 8989; the app hangs indefinitely.
Expected behavior
The app should bind the callback server on 127.0.0.1:8989 before/while waiting, receive the OAuth redirect, exchange and cache the token, and proceed to the TUI.
Screenshots
Browser after approving consent:
"Unable to connect — Firefox can't connect to the server at 127.0.0.1:8989" while the URL bar shows http://127.0.0.1:8989/login?code=...
Desktop (please complete the following information):
- OS: CachyOS Linux (Arch-based), kernel 7.1.3-2-cachyos
- Terminal: kitty
- Version: 0.40.2 (also reproduced on 0.40.1); installed via AUR
spotatui-bin
Additional context
86% reproducible whenever needs_auth is true; does NOT reproduce once a valid token is cached (the buggy path is skipped), which is why it can appear to "work until it suddenly doesn't." Verified locally: built with the one-line change above — before the fix, port 8989 never appeared in ss -tlnp across 10+ attempts; after the fix it binds immediately every time (LISTEN 0 128 127.0.0.1:8989 users:(("spotatui",pid=...,fd=10))) and login completes end-to-end.
Describe the bug
When Spotify authentication is required on startup (no valid cached token — e.g. first install, or an expired/invalidated cached token), the app prints
Waiting for authorization callback on http://127.0.0.1:8989...and hangs forever. The browser opens and Spotify's consent screen works, but after approving, the redirect tohttp://127.0.0.1:8989/login?code=...shows "Unable to connect" — nothing is ever bound to that port (confirmed withss -tlnp). The process doesn't crash; it just sits idle indefinitely.Root cause: in
src/core/auth.rs,ensure_auth_tokenis anasync fnbut calls the blockingredirect_uri_web_server(auth_port)(line 334) directly, with nospawn_blocking. That function usesstd::net::TcpListenerand blocks the tokio worker thread instead of yielding, so the listener never reliably reachesbind()/accept(). The file already has an async-safe version —redirect_uri_web_server_async(src/infra/redirect_uri.rs:90) — which is used for the in-TUI login flow but not for this startup path.Fix (one line):
To Reproduce
Steps to reproduce the behavior:
~/.config/spotatui/streaming_cache/and any cached token), soneeds_authis true.spotatui; it printsWaiting for authorization callback on http://127.0.0.1:8989...and opens the browser.http://127.0.0.1:8989/login?code=...→ "Unable to connect".ss -tlnpshows nothing listening on 8989; the app hangs indefinitely.Expected behavior
The app should bind the callback server on 127.0.0.1:8989 before/while waiting, receive the OAuth redirect, exchange and cache the token, and proceed to the TUI.
Screenshots
Browser after approving consent:
Desktop (please complete the following information):
spotatui-binAdditional context
86% reproducible whenever
needs_authis true; does NOT reproduce once a valid token is cached (the buggy path is skipped), which is why it can appear to "work until it suddenly doesn't." Verified locally: built with the one-line change above — before the fix, port 8989 never appeared inss -tlnpacross 10+ attempts; after the fix it binds immediately every time (LISTEN 0 128 127.0.0.1:8989 users:(("spotatui",pid=...,fd=10))) and login completes end-to-end.