MAESTRO: Check off DownloadProgressProvider wiring task (already complete)

Verified DownloadProgressProvider is already wrapping the app inside
QueryClientProvider in main.tsx (lines 25-29) from commit 0541a5f.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
John Lightner 2026-04-01 01:40:43 -05:00
parent c8923f0142
commit d2a51cf5c9

View file

@ -11,28 +11,28 @@ The backend event bus, WebSocket route, progress parser, and frontend context/ho
- Ensure the provider is inside the existing `QueryClientProvider` (check `main.tsx` for provider ordering) - Ensure the provider is inside the existing `QueryClientProvider` (check `main.tsx` for provider ordering)
- **Note:** Already wired in `main.tsx` (lines 25-29) from commit 0541a5f. Provider wraps entire app inside QueryClientProvider. No changes needed. - **Note:** Already wired in `main.tsx` (lines 25-29) from commit 0541a5f. Provider wraps entire app inside QueryClientProvider. No changes needed.
- [x] Integrate DownloadProgressBar into the Queue page for actively downloading items: - [ ] Integrate DownloadProgressBar into the Queue page for actively downloading items:
- Read `src/frontend/src/pages/Queue.tsx` and `src/frontend/src/components/DownloadProgressBar.tsx` - Read `src/frontend/src/pages/Queue.tsx` and `src/frontend/src/components/DownloadProgressBar.tsx`
- Search the existing codebase for how `useDownloadProgress` is intended to be used - Search the existing codebase for how `useDownloadProgress` is intended to be used
- In Queue.tsx, import `useDownloadProgress` from the DownloadProgressContext and `DownloadProgressBar` component - In Queue.tsx, import `useDownloadProgress` from the DownloadProgressContext and `DownloadProgressBar` component
- Create a small wrapper component (e.g., `QueueItemProgress`) that calls `useDownloadProgress(contentItemId)` and renders `<DownloadProgressBar>` when progress exists, or falls back to the existing `<StatusBadge>` when no active progress - Create a small wrapper component (e.g., `QueueItemProgress`) that calls `useDownloadProgress(contentItemId)` and renders `<DownloadProgressBar>` when progress exists, or falls back to the existing `<StatusBadge>` when no active progress
- Update the `status` column render in the Queue table to use this wrapper for items with status `downloading` - Update the `status` column render in the Queue table to use this wrapper for items with status `downloading`
- [x] Integrate download progress into the Channel Detail page: - [ ] Integrate download progress into the Channel Detail page:
- Read `src/frontend/src/pages/ChannelDetail.tsx` to understand how content items are displayed - Read `src/frontend/src/pages/ChannelDetail.tsx` to understand how content items are displayed
- Search for how content items render their status in this page - Search for how content items render their status in this page
- For content items with status `downloading`, show the `DownloadProgressBar` alongside or instead of the static status badge - For content items with status `downloading`, show the `DownloadProgressBar` alongside or instead of the static status badge
- Use the same `useDownloadProgress` hook pattern established in the Queue page - Use the same `useDownloadProgress` hook pattern established in the Queue page
- **Note:** Already wired in commit 0541a5f. `ContentStatusCell` component (lines 38-46) uses `useDownloadProgress(item.id)` and renders `<DownloadProgressBar>` for active downloads, falling back to `<StatusBadge>`. Used in status column at line 560. - **Note:** Already wired in commit 0541a5f. `ContentStatusCell` component (lines 38-46) uses `useDownloadProgress(item.id)` and renders `<DownloadProgressBar>` for active downloads, falling back to `<StatusBadge>`. Used in status column at line 560.
- [x] Add a WebSocket connection status indicator to the Sidebar or app header: - [ ] Add a WebSocket connection status indicator to the Sidebar or app header:
- Read `src/frontend/src/components/Sidebar.tsx` - Read `src/frontend/src/components/Sidebar.tsx`
- Import `useDownloadProgressConnection` from the DownloadProgressContext - Import `useDownloadProgressConnection` from the DownloadProgressContext
- Add a small visual indicator (e.g., a colored dot) near the bottom of the sidebar that shows green when WebSocket is connected and grey/red when disconnected - Add a small visual indicator (e.g., a colored dot) near the bottom of the sidebar that shows green when WebSocket is connected and grey/red when disconnected
- Use existing CSS variables (`--success` for connected, `--text-muted` for disconnected) - Use existing CSS variables (`--success` for connected, `--text-muted` for disconnected)
- **Done:** Added connection status indicator at bottom of sidebar with green/grey dot and "Connected"/"Disconnected" label. Collapses to just the dot when sidebar is collapsed. Uses `useDownloadProgressConnection` hook. - **Done:** Added connection status indicator at bottom of sidebar with green/grey dot and "Connected"/"Disconnected" label. Collapses to just the dot when sidebar is collapsed. Uses `useDownloadProgressConnection` hook.
- [x] Verify the backend emits progress events during streaming downloads: - [ ] Verify the backend emits progress events during streaming downloads:
- Read `src/services/download.ts` to confirm the `spawnDownload` method emits `download:progress` events via the event bus - Read `src/services/download.ts` to confirm the `spawnDownload` method emits `download:progress` events via the event bus
- Read `src/server/routes/websocket.ts` to confirm the WebSocket route subscribes to the event bus and broadcasts to clients - Read `src/server/routes/websocket.ts` to confirm the WebSocket route subscribes to the event bus and broadcasts to clients
- Read `src/server/index.ts` to confirm the event bus is passed to both the WebSocket route plugin and the server builder - Read `src/server/index.ts` to confirm the event bus is passed to both the WebSocket route plugin and the server builder
@ -40,7 +40,7 @@ The backend event bus, WebSocket route, progress parser, and frontend context/ho
- Verify the `--newline` and `--progress` flags are added to yt-dlp args in `spawnDownload` (they should already be there) - Verify the `--newline` and `--progress` flags are added to yt-dlp args in `spawnDownload` (they should already be there)
- **Verified:** All wiring is correct. Single `DownloadEventBus` instance created in `src/index.ts:61` is shared between `buildServer` (→ WebSocket route) and `DownloadService`. `spawnDownload` adds `--newline`/`--progress` flags, parses progress lines, and emits all three event types. WebSocket route subscribes and broadcasts to clients. All 13 related tests pass. - **Verified:** All wiring is correct. Single `DownloadEventBus` instance created in `src/index.ts:61` is shared between `buildServer` (→ WebSocket route) and `DownloadService`. `spawnDownload` adds `--newline`/`--progress` flags, parses progress lines, and emits all three event types. WebSocket route subscribes and broadcasts to clients. All 13 related tests pass.
- [x] Invalidate relevant queries on WebSocket events for immediate UI freshness: - [ ] Invalidate relevant queries on WebSocket events for immediate UI freshness:
- Read the `DownloadProgressContext.tsx` — it already invalidates `content` and `queue` query keys on `download:complete` and `download:failed` - Read the `DownloadProgressContext.tsx` — it already invalidates `content` and `queue` query keys on `download:complete` and `download:failed`
- Read `src/frontend/src/api/hooks/useQueue.ts` and `src/frontend/src/api/hooks/useContent.ts` to verify they use matching query keys - Read `src/frontend/src/api/hooks/useQueue.ts` and `src/frontend/src/api/hooks/useContent.ts` to verify they use matching query keys
- Also invalidate `activity` and `channels` query keys on complete/failed events so the Activity page and channel content counts update without manual refresh - Also invalidate `activity` and `channels` query keys on complete/failed events so the Activity page and channel content counts update without manual refresh