From 063e0fa76e3f249a77948d3b8d49b56e5c7ebcb8 Mon Sep 17 00:00:00 2001 From: dave Date: Tue, 31 Mar 2026 10:55:02 +0000 Subject: [PATCH] storkit: create 450_bug_web_ui_silently_swallows_chat_errors_including_oauth_login_link --- ...auth_callback_url_ignores_port_cli_flag.md | 27 ------------------- ..._chat_errors_including_oauth_login_link.md | 27 +++++++++++++++++++ 2 files changed, 27 insertions(+), 27 deletions(-) delete mode 100644 .storkit/work/1_backlog/449_bug_oauth_callback_url_ignores_port_cli_flag.md create mode 100644 .storkit/work/1_backlog/450_bug_web_ui_silently_swallows_chat_errors_including_oauth_login_link.md diff --git a/.storkit/work/1_backlog/449_bug_oauth_callback_url_ignores_port_cli_flag.md b/.storkit/work/1_backlog/449_bug_oauth_callback_url_ignores_port_cli_flag.md deleted file mode 100644 index 63b1a9ba..00000000 --- a/.storkit/work/1_backlog/449_bug_oauth_callback_url_ignores_port_cli_flag.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -name: "OAuth callback URL ignores --port CLI flag" ---- - -# Bug 449: OAuth callback URL ignores --port CLI flag - -## Description - -OAuthState is initialized with `resolve_port()` (reads STORKIT_PORT env var, defaults to 3001) instead of the actual port the server is listening on. When the server is started with `--port 4000`, the OAuth callback URL is still generated as `http://localhost:3001/callback`, so the Anthropic redirect lands on the wrong server and the state parameter lookup fails with "Unknown or expired state parameter". - -## How to Reproduce - -Start storkit with `--port 4000` (without setting STORKIT_PORT env var). Click the OAuth login button in the web UI. Authenticate with Anthropic. The callback redirect goes to localhost:3001 instead of localhost:4000. - -## Actual Result - -Callback hits port 3001 (or wrong port). If a different storkit is running there, it returns "Invalid State". If nothing is running there, the page fails to load. - -## Expected Result - -Callback URL should use the actual server port (from --port CLI flag), so the redirect returns to the correct server instance. - -## Acceptance Criteria - -- [ ] build_routes receives the actual listening port and passes it to OAuthState::new -- [ ] OAuth callback URL matches the port the server is actually listening on -- [ ] Works with --port flag, STORKIT_PORT env var, and default port diff --git a/.storkit/work/1_backlog/450_bug_web_ui_silently_swallows_chat_errors_including_oauth_login_link.md b/.storkit/work/1_backlog/450_bug_web_ui_silently_swallows_chat_errors_including_oauth_login_link.md new file mode 100644 index 00000000..50efe07c --- /dev/null +++ b/.storkit/work/1_backlog/450_bug_web_ui_silently_swallows_chat_errors_including_oauth_login_link.md @@ -0,0 +1,27 @@ +--- +name: "Web UI silently swallows chat errors including OAuth login link" +--- + +# Bug 450: Web UI silently swallows chat errors including OAuth login link + +## Description + +When the WebSocket chat returns an error (e.g. OAuth authentication failed with a login URL), the `onError` handler in `Chat.tsx` only logs to `console.error` and resets loading state. The error message is never displayed to the user. This means the OAuth login link from story #448 works on Matrix/WhatsApp but is invisible in the web UI. + +## How to Reproduce + +Use the web UI with missing or expired OAuth credentials. Send any chat message. The server detects auth failure, attempts token refresh, fails, and returns an error containing a login URL over WebSocket. + +## Actual Result + +Nothing visible happens. The error is logged to browser console only. The user sees no feedback. + +## Expected Result + +The error message (including the clickable OAuth login link) should be displayed in the chat as an assistant message so the user can act on it. + +## Acceptance Criteria + +- [ ] WebSocket error messages are displayed in the chat UI as assistant messages +- [ ] OAuth login URL in the error is rendered as a clickable link +- [ ] Consistent with how Matrix and WhatsApp transports display the same error