Bug / Feature Enhancement: Race Conditions and State Mismatch in Concurrent Attendance Logging and Curriculum Synchronization
Description
While stress-testing the attendance management and curriculum planning synchronization modules, a critical data race condition was identified. When multiple instructors attempt to log bulk attendance for overlapping student cohorts simultaneously while a curriculum coordinator updates the respective module milestones, the state machine enters an inconsistent state. This leads to intermittent database deadlocks or phantom reads (stale attendance tokens being written over updated curriculum prerequisites).
Steps to Reproduce
- Log in with Account A (Instructor) and initiate a bulk attendance submission for a cohort of 60+ students.
- Simultaneously, log in with Account B (Curriculum Admin) and push a real-time update/restructure to the specific curriculum unit tied to that active session block.
- Simulate high network latency or trigger concurrent API requests to
/api/v1/attendance/bulk and /api/v1/curriculum/update.
- Observe that some student attendance records fail to map to the updated curriculum node ID, or throw an unhandled 500 internal server error due to foreign key constraint mismatches during the transition.
Actual Behavior
- The application undergoes a silent failure or throws a database deadlock error (
Error: ER_LOCK_DEADLOCK / PostgreSQL equivalent).
- Attendance is marked "present" for a non-existent or stale curriculum block ID because the transaction boundary didn't isolate the concurrent writes.
Expected Behavior
- The system should implement pessimistic or optimistic locking mechanisms to ensure sequence integrity.
- If a curriculum structure updates mid-session, the active attendance transaction must either complete under a version-controlled snapshot of the old schema or gracefully queue until the structural write lock is released.
Comprehensive Roadmap for Resolution (Architecture Points)
To make Learnova completely bulletproof under peak institutional loads, we should address this across the following layers:
1. Database & Transaction Isolation
- Optimistic Concurrency Control (OCC): Introduce a
version column to the Curriculum and Attendance schemas. Any write operation must verify that the version hasn't changed post-fetch.
- Explicit Transaction Locks: For critical bulk endpoints, utilize
SELECT ... FOR UPDATE to block concurrent mutations on the exact cohort row until the attendance arrays are safely committed.
2. API Gateways & Request Queueing
- Idempotency Keys: Require an
X-Idempotency-Key header for bulk attendance POST requests. This prevents double-submitting if an instructor clicks "Submit" multiple times during a network lag spike.
- Message Throttling/Queueing: For large universities, offload heavy bulk attendance logging to a background worker queue (e.g., Redis/BullMQ) instead of handling processing synchronously on the main HTTP thread.
3. Frontend Optimizations & UX State Preservation
- Optimistic UI Updates with Rollback: The UI should visually confirm attendance immediately to keep the experience snappy, but retain an atomic rollback state in the client cache (e.g., React Query / Redux) if the backend returns a sync collision error.
- State Interlocking: Temporarily disable or display a non-intrusive warning banner to instructors if a curriculum coordinator has locked the active syllabus branch for maintenance.
4. Diagnostic Logging & Error Handling
- Wrap bulk queries in explicit try/catch blocks that specifically isolate deadlock retries (e.g., maximum 3 automated retry attempts before throwing a user-facing error).
- Implement structured logging displaying
cohort_id, session_token, and mutation_timestamp to easily audit future sync anomalies.
Bug / Feature Enhancement: Race Conditions and State Mismatch in Concurrent Attendance Logging and Curriculum Synchronization
Description
While stress-testing the attendance management and curriculum planning synchronization modules, a critical data race condition was identified. When multiple instructors attempt to log bulk attendance for overlapping student cohorts simultaneously while a curriculum coordinator updates the respective module milestones, the state machine enters an inconsistent state. This leads to intermittent database deadlocks or phantom reads (stale attendance tokens being written over updated curriculum prerequisites).
Steps to Reproduce
/api/v1/attendance/bulkand/api/v1/curriculum/update.Actual Behavior
Error: ER_LOCK_DEADLOCK/ PostgreSQL equivalent).Expected Behavior
Comprehensive Roadmap for Resolution (Architecture Points)
To make
Learnovacompletely bulletproof under peak institutional loads, we should address this across the following layers:1. Database & Transaction Isolation
versioncolumn to theCurriculumandAttendanceschemas. Any write operation must verify that the version hasn't changed post-fetch.SELECT ... FOR UPDATEto block concurrent mutations on the exact cohort row until the attendance arrays are safely committed.2. API Gateways & Request Queueing
X-Idempotency-Keyheader for bulk attendance POST requests. This prevents double-submitting if an instructor clicks "Submit" multiple times during a network lag spike.3. Frontend Optimizations & UX State Preservation
4. Diagnostic Logging & Error Handling
cohort_id,session_token, andmutation_timestampto easily audit future sync anomalies.