fix(desktop): board auto-retry on server startup#30
Merged
Conversation
…ate instead of static error Add useBoardServerReady hook that polls /health every 2s until the board server responds, then stops. BoardProjectsPage and BoardKanbanPage now gate their API calls on ready===true and show "Connecting to board server..." during the wait. Eliminates the race condition where the React frontend loads before the board-server is ready on :4800. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…, hook tests - Replace AbortSignal.timeout() with AbortController+setTimeout for compatibility with older WKWebView versions (macOS 12/13) - Initialize useBoardData loading to false (no fetch in-flight until ready=true; callers gate on !ready||loading so behavior is unchanged) - Add useBoardServerReady tests: initial state, ok/non-ok response, retry timing, stops-after-ready, unmount cleanup (183 tests total) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Un-ignore .devlaunch.yml so project launch config is shared. Fixes broken pnpm install:desktop and watch:desktop references that don't exist in package.json. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… guard setReady after unmount - Test now imports BOARD_SERVER_BASE from board-api instead of hardcoding the URL string, so it stays in sync if the constant changes - useBoardServerReady: track mounted flag in effect closure; skip setReady if component unmounts before in-flight fetch resolves Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When running
dev:desktop, the board-server starts in the background and there's a race condition: the React frontend loads before the server is ready on:4800. Previously, a single failed HTTP request would show a static error forever ("Could not connect to board server" / "Is the board server running on :4800?"). This PR makes the board pages resilient by polling for server readiness before attempting data fetches.Changes
useBoardServerReady.ts(new hook) — pollsGET /healthevery 2s until the server responds, then stops. Cleans up the interval on unmount.useBoardData.ts— accepts areadyboolean param (defaulttruefor backwards compat); skips the initial fetch untilready.BoardProjectsPage.tsx— usesuseBoardServerReady, gatesapi.projects.list()onready, shows "Connecting to board server..." during startup instead of a static error.BoardKanbanPage.tsx— same pattern; passesreadytouseBoardData; removes the ":4800" hint from post-connection errors since the server is confirmed running by that point.Test Plan
pnpm dev:desktop— board page shows "Connecting..." briefly then loads (or "No projects yet" if empty)pnpm exec tsc --noEmitinapps/desktop— no errorsNotes
tauri.conf.jsonis unchanged — thebeforeDevCommand&background launch is correct; the frontend just needs to be resilient to slow startup. The WebSocket hook already had retry logic; this aligns HTTP fetching with the same pattern.