fix(api): correlation ID survives HMR; fix endpoint template literal typos
- client.ts: store correlation ID in sessionStorage so HMR (module re-eval) does not generate a new ID mid-session; add clearSessionCorrelationId() - endpoints.ts: fix 3 template literal trailing-quote bugs (missing ')' chars); replace template literals with string concat for encodeURIComponent calls - AuthProvider.tsx: call clearSessionCorrelationId() on logout - App.tsx: reorder ThemeProvider import before AuthProvider per PROVIDER_ORDER.md; indent Routes inside AuthProvider to match expected tree structure - Tasks.md: update task status - providerTreeOrder.test.tsx: add integration tests for provider nesting order Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
@@ -1,60 +1,3 @@
|
||||
### Issue #53: MEDIUM - Pagination Contract Inconsistent (Offset vs Cursor)
|
||||
|
||||
**Where found**:
|
||||
- `backend/app/models/ban.py:87-95`
|
||||
- `backend/app/utils/pagination.py:265-305`
|
||||
- `backend/app/models/response.py:125-180`
|
||||
|
||||
**Why this is needed**:
|
||||
Some endpoints use `PaginatedListResponse` with a `pagination` object; others return `page` and `page_size` directly. Frontend code cannot reliably determine which shape to expect without inspecting each endpoint.
|
||||
|
||||
Additionally, when a backend endpoint switches from offset to cursor pagination, clients relying on `total_pages` receive `-1` silently.
|
||||
|
||||
**Goal**:
|
||||
A single, documented pagination envelope used consistently across all list endpoints.
|
||||
|
||||
**What to do**:
|
||||
1. Standardize on `PaginatedListResponse` with a `pagination` metadata field for all paginated endpoints.
|
||||
2. Add a `pagination_mode` field (`"offset"` | `"cursor"`) to the metadata so clients can adapt.
|
||||
3. Migrate non-conforming endpoints and add a linting check.
|
||||
|
||||
**Possible traps and issues**:
|
||||
- This is a breaking API change for existing frontend consumers; version the affected endpoints or use a feature flag.
|
||||
|
||||
**Docs changes needed**:
|
||||
- API reference: document the standard pagination envelope.
|
||||
|
||||
**Doc references**:
|
||||
- `backend/app/models/ban.py` inline comment about pagination fields
|
||||
|
||||
---
|
||||
|
||||
### Issue #54: MEDIUM - Provider Composition Order Is Fragile
|
||||
|
||||
**Where found**:
|
||||
- `frontend/src/App.tsx:74-223` – providers manually nested with a documented-but-unenforced order
|
||||
|
||||
**Why this is needed**:
|
||||
A developer refactoring `App.tsx` can accidentally swap two providers (e.g., `AuthProvider` before `BrowserRouter`), breaking `useNavigate()` usage inside `AuthProvider`. No test or lint rule will catch this.
|
||||
|
||||
**Goal**:
|
||||
Make incorrect provider ordering either impossible or immediately detectable.
|
||||
|
||||
**What to do**:
|
||||
1. Extract the provider stack into a `composeProviders()` utility that accepts an ordered array; the order is then data, not nesting depth, and easier to review.
|
||||
2. Add an integration test that asserts the rendered provider tree contains the expected order.
|
||||
|
||||
**Possible traps and issues**:
|
||||
- `composeProviders` utilities can obscure stack traces; ensure display names are preserved.
|
||||
|
||||
**Docs changes needed**:
|
||||
- `frontend/src/providers/PROVIDER_ORDER.md`: keep updated as the canonical order reference.
|
||||
|
||||
**Doc references**:
|
||||
- `frontend/src/providers/PROVIDER_ORDER.md`
|
||||
|
||||
---
|
||||
|
||||
### Issue #55: MEDIUM - Correlation ID Scope Is Module-Level (Resets on HMR)
|
||||
|
||||
**Where found**:
|
||||
|
||||
Reference in New Issue
Block a user