- 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
- 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
- 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
- Update Track type in types/api.ts to extend VezaBackendApiInternalModelsTrack
- Update Track type in features/tracks/types/track.ts to extend generated type
- Preserve UI-specific computed fields (coverUrl, plays, likes, etc.)
- Support backward compatibility for duration (number|string)
- All existing imports continue to work without changes
- No Track-specific TypeScript errors introduced
- Replace manual ApiError interface with Zod-inferred type from apiSchemas
- Update all imports (15+ files) to use ApiError from @/schemas/apiSchemas
- Remove ApiError interface from types/api.ts
- Update ApiResponse to import ApiError from schemas
- All TypeScript checks pass for ApiError-related code
- Install husky as dev dependency
- Create pre-commit hook to run type generation script
- Ensures types are always up-to-date with backend API before commit
- Hook runs from apps/web directory to execute generate-types.sh
- Backend: Add X-API-Deprecated header alongside existing X-API-Version-Deprecated
- Frontend: Show deprecation warning toast when deprecated API version detected
- Warning shown only once per session to avoid spam
- Includes sunset date in warning message if available
- Migrated all hooks: useAuth, useChat, useLogin
- Migrated all components: Header, ProfileForm, FollowButton, LikeButton, PlaylistFollowButton, ChatMessage, ChatMessages, CommentThread, CommentSection, PlaylistList, ChatSidebar, SettingsPage, DashboardPage
- Updated storeSelectors.ts useAuthUser() to use React Query
- All production code now uses useUser() hook instead of Zustand store
- Action 4.1.1.3 and 4.1.1.4 complete
- Remove items, favorites, pagination, isLoading, error from LibraryState
- Remove fetchItems, fetchFavorites, uploadFile, toggleFavorite, deleteItem, clearItems, setLoading, setError from LibraryActions
- Remove undoRedo and stateMiddleware wrappers (no domain data to track)
- Update useLibraryActions() to use React Query for all domain data actions
- Store now only contains filters (UI state)
- Update useLibraryItemsNormalized() and useLibraryFavoritesNormalized() to return empty state (deprecated)
- Update useLibraryPagination() to return both camelCase and snake_case for compatibility
Action 4.1.2.4 complete
- Replace useLibraryItems() with React Query hook
- Replace useLibraryFavorites() with React Query hook
- Replace useLibraryPagination() to extract from React Query response
- Replace useLibraryStatus() to use React Query status
- Update useLibraryActions() to use queryClient.refetchQueries()
- Maintain same interface for backward compatibility
- Migrates DashboardPage components automatically
Action 4.1.2.3.3 complete
- Completed Action 2.2.1.1: Removed client-side filter logic from LibraryPage
- Removed unnecessary useMemo that was just passing through tracksData?.tracks
- Simplified to direct assignment: filteredTracks = tracksData?.tracks || []
- Backend handles all filtering (verified in Action 2.2.1.2)
- No actual filtering was happening - useMemo was just a pass-through
- Code simplified, behavior unchanged
- Completed Action 2.2.1.3: Handled LibraryPage.tsx vs LibraryPagePremium.tsx duplication
- Updated LIBRARY_PAGE_AUDIT.md with file comparison
- Verified LibraryPage.tsx is active (imported via LazyLibrary in routing)
- Verified LibraryPagePremium.tsx is duplicate/unused (not imported anywhere)
- LibraryPagePremium.tsx is older version without debounce improvements
- Removed LibraryPagePremium.tsx - safe deletion, no references found
- Routing continues to use LibraryPage.tsx, no breakage
- Completed Action 2.2.1.5: Removed LibraryPage.tsx.old
- File verified as safe to delete (no imports/references found in Action 2.2.1.4)
- Cleanup of obsolete backup file
- Active LibraryPage.tsx remains unchanged
- Completed Action 2.2.1.4: Verified LibraryPage.tsx.old has no imports
- Created LIBRARY_PAGE_AUDIT.md documenting file status
- Confirmed LibraryPage.tsx.old is safe to delete (no references)
- Identified LibraryPagePremium.tsx as duplicate/unused (needs Action 2.2.1.3)
- Active LibraryPage.tsx is imported via LazyComponent in routing
- Ready for Action 2.2.1.5: Remove LibraryPage.tsx.old
- Completed Action 1.2.1.5: Enhanced request validation logic
- Improved error messages with field paths and detailed validation errors
- Added structured logging for validation failures with request context
- Validation infrastructure was already in place, now ensures robust error handling
- All requests with _requestSchema are validated before sending
- FormData requests are skipped (validated separately)
- Type safety verified, no regressions
- Completed Action 1.1.3.12: Audited all feature type files
- Created FEATURE_TYPES_AUDIT.md documenting 5 feature type files
- Identified tracks, auth, chat, roles, and settings type files
- Documented migration needs for each file
- Estimated 10-15 types need replacement with generated types
- Completed Actions 1.1.3.6-1.1.3.8: Audited dto.ts, v2-v3-types.ts, backend-types.ts
- Created TYPE_FILES_AUDIT.md documenting findings
- dto.ts: 8 DTOs can be replaced, 2 may need to stay (ValidationError)
- v2-v3-types.ts: Most types are UI-specific, 1-3 may be replaceable
- backend-types.ts: Small file, 0-2 types may be replaceable
- Documented migration paths for each file
- Completed Action 1.4.1.1: Added X-API-Version header to all requests
- Completed Action 1.4.1.4: Added API_VERSION to env config (defaults to 'v1')
- Header added in request interceptor before other headers
- Version configurable via VITE_API_VERSION environment variable
- Replaced all basic Tailwind components with Premium Glassmorphism design
- Implemented neon accents and custom scrollbars
- Added typing indicators and file upload UI polish
- Integrated Chat Page with the new Layout system
