Enhance retry logic to detect 429 rate limits, parse Retry-After headers, and apply smart backoff across all entity submissions. Adds rate-limit-aware backoff, preserves user feedback via UI events, and ensures retries respect server-provided guidance.
Add exponential backoff retry logic with user feedback
- Integrate with existing withRetry patterns
- Introduce unique retry IDs for submissions
- Emit consistent UI events for retry progress, success, and failure
- Enhance rate-limit handling including Retry-After scenarios
- Standardize baseDelay and shouldRetry across park, ride, company, ride_model, and other submissions
Extend existing alert system to include real-time monitoring for rate limit violations and ban evasion attempts. This involves adding new reporting functions to `pipelineAlerts.ts`, integrating these functions into submission and company helper files, updating the admin dashboard component to display new alert types, and creating a database migration for the new alert type.
Added `recordSubmissionAttempt(userId)` to `submitParkCreation`, `submitParkUpdate`, `submitRideCreation`, and `submitRideUpdate` in `src/lib/entitySubmissionHelpers.ts`. This ensures that rate limit counters are incremented after a successful rate limit check, closing a vulnerability that allowed for unlimited submissions of parks and rides.
Implement Phase 4 by adding `recordSubmissionAttempt` and `withRetry` logic to the ban check for composite submissions. This ensures better error handling and prevents bypass of ban checks due to transient network issues.
Implement rate limiting, ban checks, retry logic, and breadcrumb tracking for ride model creation and update functions. Wrap existing ban checks and database operations in retry logic.
Implement rate limiting, ban checks, retry logic, and breadcrumb tracking for all 8 company submission functions: manufacturer, designer, operator, and property_owner (both create and update). This ensures consistency with other protected entity types and enhances the robustness of the submission pipeline.
Implement rate limiting, validation, retry logic, and ban checking for photo and timeline submissions. This includes updates to `UppyPhotoSubmissionUpload.tsx` and `entitySubmissionHelpers.ts`.
This commit implements Phase 3 of the Sacred Pipeline, focusing on enhanced error handling. It includes:
- **Transaction Status Polling Endpoint**: A new edge function `check-transaction-status` allows clients to poll the status of moderation transactions using idempotency keys.
- **Expanded Error Sanitizer Patterns**: The `src/lib/errorSanitizer.ts` file has been updated with more comprehensive patterns to remove sensitive information from error messages, making them safer for display and logging. User-friendly replacements for common errors are also included.
- **Rate Limiting for Submission Creation**: Client-side rate limiting has been implemented in `src/lib/submissionRateLimiter.ts` and applied to key submission functions within `src/lib/entitySubmissionHelpers.ts` (e.g., `submitParkCreation`, `submitRideCreation`, `submitParkUpdate`, `submitRideUpdate`) to prevent abuse and accidental duplicate submissions.
Approve and implement the Supabase migration for the pipeline monitoring alert system. This includes expanding alert types, adding new monitoring functions, and updating existing ones with escalating thresholds.
Implement comprehensive error handling and robustness measures across the entire pipeline as per the detailed plan. This includes database-level security, client-side validation, scheduled maintenance, and fallback mechanisms for edge function failures.
Implement Phase 1 of the JSONB violation fix by creating the `park_submission_locations` table. This includes migrating existing data from `park_submissions.temp_location_data` and updating relevant code to read and write to the new relational table. The `temp_location_data` column will be dropped after data migration.
Refactor park updates, ride updates, and timeline event submissions to use dedicated relational tables instead of JSON blobs in `submission_items.item_data`. This enforces the "NO JSON IN SQL" rule, improving queryability, data integrity, and consistency across the pipeline.
Implement plan to fix ride model technical specifications pipeline. This includes creating a new migration for the `ride_model_submission_technical_specifications` table, updating `entitySubmissionHelpers.ts` to handle insertion of technical specifications, and modifying the edge function `process-selective-approval/index.ts` to fetch these specifications. This ensures no data loss for ride model technical specifications.
Implement the plan to fix critical data loss in ride submissions. This includes:
- Storing ride technical specifications, coaster statistics, and name history in submission tables.
- Adding missing category-specific fields to the `ride_submissions` table via a new migration.
- Updating submission helpers and the edge function to include these new fields.
- Fixing the park location Zod schema to include `street_address`.
Update submission and moderation pipeline to correctly handle `street_address`. This includes:
- Adding `street_address` to the Zod schema in `ParkForm.tsx`.
- Ensuring `street_address` is included in `tempLocationData` for park and composite park creations in `entitySubmissionHelpers.ts`.
- Preserving `street_address` when editing submissions in `submissionItemsService.ts`.
- Saving `street_address` when new locations are created during submission approval in `submissionItemsService.ts`.
