Missing Concurrency Control on Leaderboard Time/Attempts Updates (#75)

[Ayaanshaikh12243]

close #75

Fix Missing Concurrency Control on Leaderboard Time/Attempts Updates (#75)

Summary

This PR fixes Issue #75 by adding end-to-end concurrency controls for leaderboard submissions to prevent duplicate records, race-condition overwrites, and client-side time/attempt manipulation.

Problem

The leaderboard flow had multiple integrity gaps:

• No reliable idempotency protection for retries/network failures
• Race conditions on simultaneous submissions
• Weak timestamp-based submission identifiers
• Insufficient server/database validation for monotonic fields and timestamps

What Changed

1) Database-level protections

Added migration with stronger constraints and concurrency-safe validation:

• Added/strengthened idempotency and completion uniqueness guarantees
• Added check constraints for data sanity (time_spent, attempts, hints_used, points)
• Added optimistic-locking versioning fields and server timestamps

Implemented trigger functions:

• validate_leaderboard_update()
  • Prevents decreasing time_spent, attempts, hints_used
  • Ensures valid timestamp relationships
  • Increments version and updates modification metadata
• prevent_duplicate_completions()
  • Blocks duplicate completion writes for same team/question
  • Detects duplicate idempotency submissions
• calculate_elapsed_time()
  • Compares client-reported elapsed time vs server-derived elapsed time
  • Logs suspicious discrepancies

2) Edge-function safety (validate flow)

• Validation and leaderboard recording are handled atomically in server flow
• Duplicate/constraint conflicts are detected and handled gracefully
• Idempotency key is propagated through server path for safe retries

3) Frontend idempotency hardening

In challenge submission flow:

• Replaced timestamp-based key generation with crypto.randomUUID()
• Persisted submission UUID in localStorage per team/challenge during retry window
• Reused same UUID on retry to preserve idempotency semantics
• Cleared submission key after successful completion

Security & Integrity Impact

• Eliminates duplicate completion records from concurrent submissions
• Prevents rollback-style manipulation of progress counters
• Enforces monotonic update behavior at DB layer
• Reduces trust on client-submitted timing data

Files of Interest

• src/components/ChallengePage.tsx
• Databases/supabase/migrations/* (Issue Missing Concurrency Control on Leaderboard Time/Attempts Updates #75 concurrency migration and trigger updates)
• Docs/CONCURRENCY_CONTROL_IMPLEMENTATION.md

Testing Performed

• Simulated repeated submit/retry with same idempotency key
• Simulated near-simultaneous correct submissions for same team/question
• Verified duplicate completion attempts are rejected
• Verified monotonic fields cannot be decreased via update
• Verified UUID-based idempotency key persistence/reuse behavior

Backward Compatibility

• Existing leaderboard reads remain unaffected
• Write path is stricter by design (integrity-first)
• No UI/UX regression expected outside duplicate/race-path behavior

Rollout Notes

1. Apply Supabase migration(s)
2. Deploy updated Edge Function(s)
3. Deploy frontend changes
4. Monitor logs for trigger warnings and duplicate-attempt notices

Checklist

• Concurrency controls implemented at DB and server layers
• Frontend idempotency key generation upgraded to UUID
• Duplicate submissions handled safely
• Documentation updated

[vercel]

@Ayaanshaikh12243 is attempting to deploy a commit to the csxark's projects Team on Vercel.

A member of the Team first needs to authorize it.