- Changed default AccessTokenTTL from 15 minutes to 5 minutes in jwt_service.go
- Updated test mock in mocks_test.go to match new default
- All references to AccessTokenTTL automatically use new value
- Tests pass successfully
- No breaking changes - frontend already handles token refresh
- Action 5.1.1.4 complete
- Integrated useFormValidation into features/auth/components/RegisterForm.tsx
- Integrated useFormValidation into features/auth/components/LoginForm.tsx
- Integrated useFormValidation into components/forms/RegisterForm.tsx
- Integrated useFormValidation into components/forms/LoginForm.tsx
- All forms now use backend pre-validation with debouncing (300ms)
- Backend validation errors displayed alongside client-side errors
- Note: Other forms require backend validation types to be added first
- Action 5.2.1.4 complete
- Integrated useFormValidation hook into RegisterForm
- Integrated useFormValidation hook into LoginForm
- Validation triggers on form data change (debounced 300ms)
- Backend validation errors displayed alongside client-side errors
- Errors mapped to correct form fields
- Uses watch() from react-hook-form to monitor form changes
- Handles field name mapping (password_confirm vs password_confirmation)
- No TypeScript errors
- Action 5.2.1.2 complete
- Created useFormValidation hook with validate function
- Accepts validation type (e.g., "RegisterRequest", "LoginRequest")
- Calls /api/v1/validate endpoint with type and data
- Returns validation state: isValidating, errors, isValid, error
- Provides clear() function to reset validation state
- Handles both wrapped and direct API response formats
- Uses parseApiError for consistent error handling
- Exported from hooks/index.ts with types
- No TypeScript errors
- Follows existing hook patterns
- Action 5.2.1.3 complete
- Created ValidateHandler with Validate method
- Endpoint accepts POST /api/v1/validate with type and data
- Supports RegisterRequest and LoginRequest validation types
- Uses existing validator from CommonHandler
- Returns ValidateResponse with valid flag and errors array
- Public endpoint (no auth required)
- Route registered in setupValidateRoutes
- Code compiles successfully
- Follows existing handler patterns
- Action 5.2.1.1 complete
- Created useIsRateLimited() hook to check rate limit state
- Updated CommentSection submit button to disable when rate limited
- Updated LikeButton to disable when rate limited
- Updated PlaylistForm submit button to disable when rate limited
- Updated ChatInput send button to disable when rate limited
- Updated UploadModal upload button to disable when rate limited
- All buttons check isLimited from rate limit store
- Hook uses Zustand selector for efficient re-renders
- Pattern established for future mutation buttons
- Action 5.4.1.4 complete
- Action 5.4.1.5: Countdown timer already implemented in RateLimitIndicator
- Action 5.4.1.7: Store integration already implemented via useRateLimitStore()
- Both actions were completed as part of Action 5.4.1.2
- Added RateLimitIndicator component to Header
- Placed after NotificationMenu for visibility
- Component automatically shows/hides based on rate limit state
- No TypeScript errors
- Action 5.4.1.3 complete
- Created RateLimitIndicator component to display rate limit status
- Shows when user is rate limited or when remaining < 20% of limit
- Displays remaining requests (e.g., "50/100 requests")
- Shows countdown timer until reset (formatted as "5m 30s" or "1h 15m")
- Uses AlertTriangle and Clock icons from lucide-react
- Color-coded: red for critical (rate limited), gold for warning (< 20% remaining)
- Updates timer every second using useEffect
- Returns null when no rate limit data or not limited
- Follows existing component patterns (similar to OfflineIndicator)
- Action 5.4.1.2 complete
- Created rate limit store (apps/web/src/stores/rateLimit.ts) to store parsed headers
- Added header parsing in success response interceptor:
- X-RateLimit-Limit: Maximum requests allowed
- X-RateLimit-Remaining: Requests remaining
- X-RateLimit-Reset: Unix timestamp when limit resets
- Added header parsing in error response interceptor:
- Includes Retry-After header for 429 errors
- All rate limit headers parsed from both lowercase and uppercase variants
- Store automatically updated on every API response
- Store includes isLimited flag calculated from remaining/retryAfter
- Uses Zustand with persistence for cross-tab state
- Actions 5.4.1.1 and 5.4.1.6 complete
- Added "Copy Request ID" button that copies request ID to clipboard
- Button appears for server errors when request_id is available
- Uses modern Clipboard API with fallback to execCommand
- Shows success toast when copied
- Added alongside existing "Report Issue" button
- Fixed TypeScript error in isServerError calculation
- Action 5.3.1.2 complete
- Removed development-only check for request ID in formatErrorMessage function
- Request ID now always included when includeRequestId parameter is true
- Improves error correlation in production environments
- Updated comment to reflect change
- Action 5.3.1.1 complete
- Added optimistic updates to notification mutations:
- markAsReadMutation: Optimistically marks notification as read
- markAllAsReadMutation: Optimistically marks all notifications as read
- Updated in both NotificationsPage and NotificationMenu
- Added optimistic updates to share link mutations:
- createShareMutation: Optimistically adds share link to local state
- revokeShareMutation: Optimistically removes share link from local state
- Added optimistic updates to chat mutations:
- leaveRoomMutation: Optimistically removes conversation from list
- deleteRoomMutation: Optimistically removes conversation from list
- Added optimistic update to reorder mutation:
- useReorderPlaylistTracks: Optimistically reorders tracks in playlist
- All mutations include:
- onMutate: Cancel queries, snapshot previous state, apply optimistic update
- onError: Rollback to previous state
- onSuccess: Invalidate queries for consistency
- Action 4.4.1.5 complete (18 mutations with optimistic updates)
- Created QueryClient singleton (queryClientSingleton.ts):
- Provides global access to QueryClient for state invalidation
- Set in main.tsx after QueryClient creation
- Updated invalidateQueries() to use QueryClient directly:
- Replaced custom event system with direct QueryClient.invalidateQueries()
- Added query key mapping for all resource types
- Event system kept as fallback if QueryClient not available
- Updated invalidateStore() for Library Store:
- Removed clearItems() call (method doesn't exist, domain data migrated to React Query)
- Library Store now only contains UI state (filters)
- React Query cache invalidation handles refetching
- Query keys mapped:
- tracks: ['tracks'], ['track'], ['library']
- playlists: ['playlists'], ['playlist']
- users: ['users'], ['user'], ['auth'], ['userProfile']
- conversations: ['conversations'], ['conversation'], ['chat'], ['chatConversations']
- roles: ['roles'], ['role']
- library: ['library'], ['tracks'], ['favorites'], ['libraryItems']
- auth: ['auth'], ['user']
- Action 4.6.1.5 complete
- Removed stateMiddleware utility (431 lines):
- Deleted apps/web/src/utils/stateMiddleware.ts
- Deleted apps/web/src/utils/stateMiddleware.test.ts (251 lines)
- Completely unused in production code (only used in test file)
- Previously removed from Library Store in Action 4.1.2.7
- Library Store now only contains UI state (filters), no middleware needed
- Created audit documentation: apps/web/src/docs/STATEMIDDLEWARE_UTILITY_AUDIT.md
- Action 4.6.1.4 complete
- Removed undoRedo utility (8587 bytes):
- Deleted apps/web/src/utils/undoRedo.ts
- Removed WithUndoRedo<T> type from stores/types.ts
- Removed WithUndoRedo export from stores/index.ts
- Completely unused (confirmed in Action 4.6.1.9 audit)
- Removed stateNormalization utility (6321 bytes):
- Deleted apps/web/src/utils/stateNormalization.ts
- Updated stores.test.ts to remove outdated tests:
- Removed createEmptyNormalized import
- Removed outdated Library Store tests (items/favorites)
- Updated Library Store tests to test current structure (filters only)
- Updated Chat Store tests to use feature store
- Updated Auth Store tests (user data migrated to React Query)
- Fixed beforeEach to not call non-existent methods
- Only used in outdated test file (confirmed in Action 4.6.1.11 audit)
- Both utilities made obsolete by React Query migration
- Actions 4.6.1.10 and 4.6.1.12 complete
- Audited undoRedo utility: completely unused (no imports found)
- Only type exports remain (WithUndoRedo) but also unused
- Previously removed from Library Store in Action 4.1.2.5
- Safe to remove (Action 4.6.1.10)
- Audited stateNormalization utility: only used in outdated test
- Only createEmptyNormalized used in stores.test.ts
- Tests check obsolete Library Store structure (items/favorites)
- Library Store migrated to React Query in Action 4.1.2.6
- Safe to remove after updating test file (Action 4.6.1.12)
- Created audit documentation:
- apps/web/src/docs/UNDOREDO_UTILITY_AUDIT.md
- apps/web/src/docs/STATENORMALIZATION_UTILITY_AUDIT.md
- Actions 4.6.1.9 and 4.6.1.11 complete
- Removed duplicate stores/chat.ts (old store)
- Consolidated to features/chat/store/chatStore.ts (active store)
- Updated ChatMessages.tsx to use feature store (currentConversationId + lookup)
- Updated storeSelectors.ts to use feature store and export only existing methods
- Updated stateHydration.ts to skip chat hydration (uses React Query)
- Updated stateInvalidation.ts to not call fetchConversations (React Query handles it)
- Updated stores/index.ts to export feature store
- Updated documentation
- Test files still reference old store (separate update needed)
- Action 4.5.1.5 complete
- Deleted apps/web/src/utils/optimisticStoreUpdates.ts (unused file)
- File was unused - no imports found in codebase
- Mutations already use React Query's onMutate pattern
- No TypeScript errors after deletion
- Actions 4.4.1.2 and 4.4.1.3 complete
- Added optional onStateSync callback to BroadcastSyncOptions
- Callback is called when state is updated locally or synced from another tab
- Callback receives new state and previous state as parameters
- Error handling prevents callback errors from breaking sync
- Stores can opt-in by providing callback that invalidates React Query queries
- No breaking changes - callback is optional
- Action 4.2.1.1 complete
- Removed _refreshUserPromise from AuthState interface
- Removed _refreshUserPromise from initial state
- Field no longer needed - React Query handles deduplication automatically
- No references to field remain in codebase
- Action 4.3.1.3 complete
- Removed manual promise deduplication logic (_refreshUserPromise usage)
- Removed promise creation and storage
- Simplified to direct async function that calls getMe()
- React Query's useUser hook handles deduplication automatically
- Preserved all error handling and state preservation logic
- Function simplified from 83 lines to 58 lines
- Action 4.3.1.2 complete
- Removed user field from AuthState interface
- Removed all user assignments in login, register, logout, refreshUser, checkAuthStatus
- Updated refreshUser to verify auth via getMe() but not store user (React Query handles that)
- Updated checkAuthStatus to verify auth via getMe() but not store user
- Updated persist partialize to not store user (only isAuthenticated)
- Updated broadcastSync shouldSync to only check isAuthenticated
- Removed User import
- Store now only manages isAuthenticated boolean
- User data exclusively managed by React Query (useUser hook)
- All production code already migrated (Actions 4.1.1.3-4.1.1.4 complete)
- Action 4.1.1.5 complete
- Tests already exist in response_test.go
- All tests passing (verified with go test)
- Tests cover all response helper functions
- Tests verify wrapped format for success and error responses
- Action 1.3.2.5 complete
- Created OfflineQueueManager component to display queued requests
- Shows request details: method, URL, timestamp, priority, retry count
- Allows removing individual requests
- Allows clearing entire queue
- Auto-updates queue every second while dialog is open
- Priority badges with color coding
- Empty state when no requests queued
- Uses Dialog component for modal display
- Action 2.5.1.4 complete
- Action 2.3.1.4 was already implemented in Action 2.3.1.1
- Message deduplication uses processedMessages Set to track message IDs
- Prevents duplicate cache updates from same message
- Includes cleanup of old processed message IDs
- Action 2.3.1.4 complete
- Added documentation explaining coexistence of Zustand and React Query sync
- Added type guards in broadcastSync.ts to verify message format before processing
- Added type guards in reactQuerySync.ts to verify message format before processing
- Both sync mechanisms use different channel names (no direct conflicts)
- Both sync mechanisms use different message formats (no cross-processing)
- Type guards ensure handlers only process their own message types
- Prevents accidental cross-processing of messages between sync mechanisms
- Both syncs can coexist safely without conflicts
- Action 2.3.1.3 complete
- Added useQueryClient hook to App component
- Added setupReactQuerySync import and initialization
- Initialize sync on App mount with cleanup on unmount
- React Query cache synchronization now active across browser tabs
- Multi-tab updates work when mutations succeed or queries are invalidated
- Action 2.3.1.2 complete
- Created reactQuerySync.ts with setupReactQuerySync() function
- Uses BroadcastChannel API to sync cache updates across browser tabs
- Subscribes to QueryClient mutation cache to broadcast mutation successes
- Subscribes to QueryClient query cache to broadcast query invalidations
- Implements message deduplication using message IDs and processed messages Set
- Implements tab ID tracking to avoid processing messages from same tab
- Handles three message types: query-invalidate, query-set-data, mutation-success
- Includes shouldSync filter function for selective synchronization
- Includes cleanup function to stop synchronization
- Focuses on invalidations and mutations (not every query update) for performance
- Comprehensive error handling and logging
- Action 2.3.1.1 complete - utility ready for integration
- Migrated useDashboard hook from useState/useEffect to React Query
- Added query key factory: dashboardQueryKeys for proper cache management
- Configured staleTime: 30 seconds (dashboard data changes frequently)
- Configured gcTime: 2 minutes (keeps data in cache)
- Added retry: 1 with retryDelay: 1000ms for automatic retry
- Preserved backward compatibility: same return interface
- Dashboard data now automatically cached and deduplicated
- Multiple components using useDashboard share cached data
- Automatic background refetching when data becomes stale
- Better performance and reduced API calls
- Action 2.1.1.7 complete - Sub-Epic 2.1.1 complete
- Removed getDashboardStats() function (old separate API call)
- Removed getRecentActivity() function (old separate API calls)
- Removed helper functions: mapActionToType, formatActivityTitle, formatActivityDescription
- Removed fallback to old methods in getDashboardData()
- Removed unused import of socialService
- All dashboard data now comes exclusively from aggregated /api/v1/dashboard endpoint
- No separate API calls remain in dashboard service
- Cleaner code, single source of truth for dashboard data
- Actions 2.1.1.5 and 2.1.1.6 complete - old API calls removed
- Updated getDashboardData() to call /api/v1/dashboard endpoint
- Added support for query parameters: activity_limit, library_limit, stats_period
- Added TrackPreview and LibraryPreview interfaces matching backend contract
- Updated DashboardData interface to include optional library_preview field
- Updated useDashboard hook to accept options and return libraryPreview
- Added fallback to old multiple-call method if new endpoint fails
- Dashboard now loads with single request instead of multiple parallel calls
- All existing functionality preserved, backward compatible during migration
- Action 2.1.1.3 complete - frontend ready to use aggregated endpoint
- Created DashboardHandler that aggregates multiple data sources
- Fetches stats, activity, and library preview in parallel
- Aggregates stats from audit logs (tracks_played, messages_sent, favorites, active_friends)
- Converts audit logs to RecentActivity format with type mapping
- Converts tracks to TrackPreview format for library preview
- Supports query parameters: activity_limit, library_limit, stats_period
- Returns wrapped format {success: true, data: DashboardResponse}
- Registered route: GET /api/v1/dashboard (protected, requires auth)
- Uses interface-based approach to avoid import cycle
- Router creates wrapper function to adapt track service
- Build successful, all handlers compile correctly
- Action 2.1.1.2 complete - dashboard endpoint ready for frontend integration
- Created comprehensive test suite for response format
- Test Success() returns wrapped format {success: true, data: {...}}
- Test Created() returns wrapped format
- Test Error() returns wrapped format for all status codes
- Test RespondWithAppError() returns wrapped format
- Test ValidationError() returns wrapped format with details
- Test all helper functions use wrapped format consistently
- All 7 test functions pass successfully (13+ test cases)
- Tests verify all response helpers return wrapped format
- Action 1.3.2.5 complete - backend response format verified
- Added comprehensive tests for wrapped format handling
- Test wrapped format with success: true and data unwrapping
- Test wrapped format with success: false and error handling
- Test wrapped format with null data
- Test safety check for non-wrapped responses (warning log)
- Test non-object response data handling
- Test verification that no direct format handling remains
- All 30 tests pass successfully
- Tests verify wrapped format only, no direct format handling
- Action 1.3.2.3 complete - response format consistency verified
- Removed direct format handling code (110+ lines)
- Removed validation and recovery logic for direct format responses
- Added safety check to log warning if non-wrapped response received
- Client now only handles wrapped format {success, data} or {success: false, error}
- Graceful degradation: non-wrapped responses still returned with warning
- TypeScript compilation successful, no linter errors
- Action 1.3.2.2 complete - frontend simplified to wrapped format only
- Updated system_metrics.go to use RespondSuccess() helper
- Updated bitrate_handler.go success responses to use wrapped format
- Updated frontend_log_handler.go to use RespondSuccess() helper
- Updated csrf.go to use RespondSuccess() and RespondWithError() helpers
- Updated audit.go: all 30+ error and success responses now use wrapped format helpers
- Updated comment_handler.go error responses to use RespondWithError()
- Updated system_metrics_test.go to expect wrapped format {success, data}
- All handlers now consistently use wrapped format helpers
- Build and tests pass successfully
- Action 1.3.2.1 complete - backend handlers standardized to wrapped format
- Added cache fallback: uses cached response for GET requests when validation fails
- Added optional retry mechanism (disabled by default, enabled via config)
- Added user notifications for recovery actions (configurable)
- Recovery config: { useCache, retry, notifyUser } on request config
- Prevents infinite retry loops with _validationRetryAttempted flag
- Validates cached responses before using them
- Handles both wrapped and direct format responses
- Graceful degradation: falls back to unvalidated data if recovery fails
- Applied to both validation sections (wrapped and direct formats)
- Action 1.2.2.5 complete - validation errors now handled gracefully
- Created ValidationAlerting class to monitor validation metrics
- Alerts when failure rate exceeds threshold (default 5%)
- Periodic checks every 5 minutes (configurable)
- Cooldown period (15 min) to prevent alert spam
- Minimum validations required (10) before alerting
- Structured alert logging with full metrics context
- Automatically starts in production (can be disabled via env var)
- Alerts sent to backend logging and Sentry
- Action 1.2.2.4 complete - validation alerting now active for monitoring
- Created ValidationMetricsTracker class to track validation metrics
- Tracks total, successful, and failed validations
- Calculates failure rate percentage
- Tracks failures by normalized endpoint patterns
- Records last failure and success timestamps
- Integrated into both validation points (wrapped and direct formats)
- Exported singleton for metrics access and monitoring
- Action 1.2.2.3 complete - validation metrics now tracked for monitoring
- Enhanced validation error logging with production monitoring context
- Added error_type field for easy filtering in monitoring systems
- Added timestamp and schema_provided flag for correlation
- Logs automatically sent to backend endpoint and Sentry in production
- Structured JSON format for easy aggregation and alerting
- Action 1.2.2.2 complete - validation failures now fully logged for production monitoring
- Enhanced response validation logging (wrapped and direct formats)
- Changed validation failures from warn to error level for better visibility
- Added structured error details (path, message, code, received, expected)
- Added response data preview for debugging
- Added success logging in debug mode
- Maintains graceful degradation (continues with unvalidated data) to avoid breaking app
- Action 1.2.2.1 complete - validation now comprehensive for all responses with schemas
- Action 1.1.3.10: Clarified that Track/User/ApiError are NOT obsolete
* ApiError already imported from schemas (not in api.ts)
* Track and User are necessary extended types with UI-specific fields
* Cannot be deleted without breaking functionality
- Action 1.1.3.11: Audited all type files for obsolete content
* No empty or redundant files found
* All type files serve a purpose (dto.ts, v2-v3-types.ts, backend-types.ts, api.ts)
* Future migration can replace DTOs with generated types (separate task)
- Both actions complete - no cleanup needed at this time
- Pre-commit hook already exists and is configured correctly
- Hook runs type generation script before each commit
- Renumbered duplicate Action 1.1.3.13 to 1.1.3.15 for clarity
- Action 1.1.3.15 complete - no changes needed
- Analyzed all extended types (User, Track) for duplicate properties
- No true duplicates found - all re-declarations serve a purpose:
* Type narrowing (making optional fields required)
* Type overrides (backward compatibility, type safety)
* UI-specific extensions (aliases, computed fields)
- Action 1.1.3.14 complete - no properties to remove
- Replace RefreshResponse with VezaBackendApiInternalDtoTokenResponse
- Replace ResendVerificationRequest with VezaBackendApiInternalDtoResendVerificationRequest
- Keep AuthResponse as is (uses extended User/AuthTokens)
- Keep form data types (frontend-specific)
- Tracks types already updated, roles/chat/settings kept as is
- Update User type in types/api.ts to extend VezaBackendApiInternalModelsUser
- Preserve UI-specific computed fields (avatar_url, stats, roles, status, etc.)
- Make required fields actually required (id, username, email, role, etc.)
- All existing imports continue to work via barrel exports
- No User-specific TypeScript errors introduced
