fix: close TOCTOU race condition in claimRecommendation

[anshul23102]

Fixes #205

Root Cause

claimRecommendation enforced the 3-active-claim cap with two sequential database operations:

1. SELECT COUNT(*) to check the current claimed count
2. UPDATE ... SET status='claimed' WHERE status='open' to write the claim

Because these are independent round-trips, a second concurrent request for the same user can execute its own COUNT query between step 1 and step 2 of the first request. Both requests see a count below 3, both pass the guard, and both commit their updates. Sending N simultaneous requests via Promise.all reliably reproduces this -- the user ends up with N active claims instead of at most 3. The existing rate limit (20 req/60s) does not prevent this because all concurrent requests land in the same window before any commit.

Fix

supabase/migrations/0012_claim_recommendation_atomic.sql

Adds a new Postgres function claim_recommendation_atomic(p_rec_id bigint, p_user_id uuid) that merges the count check and the write into a single UPDATE statement:

UPDATE recommendations AS r
SET    status = 'claimed', claimed_at = now()
WHERE  r.id      = p_rec_id
  AND  r.user_id = p_user_id
  AND  r.status  = 'open'
  AND  (
    SELECT COUNT(*) FROM recommendations r2
    WHERE  r2.user_id = p_user_id AND r2.status = 'claimed'
  ) < 3
RETURNING r.id;

The subquery that evaluates the count and the row that gets written are handled atomically by the database engine. Concurrent calls are serialised at the row level -- only one can succeed when the count is at the limit.

The function is SECURITY DEFINER with SET search_path = public to prevent search-path injection, and GRANT EXECUTE is given to both authenticated and service_role.

src/app/actions/recommendations.ts

Replaced the COUNT query and the subsequent maybeSingle UPDATE with a single service.rpc('claim_recommendation_atomic', ...) call. Zero rows returned is interpreted as a unified claim_limit_or_not_open error (covers both "limit reached" and "rec not open" cases). The UI re-fetches state on any claim error, so distinguishing the two rejection reasons is not needed client-side.

How to Test

// Reproduce the race before this fix (run in a browser console or test):
await Promise.all([
  claimRecommendation(recId1),
  claimRecommendation(recId2),
  claimRecommendation(recId3),
  claimRecommendation(recId4), // would succeed before fix
]);
// After fix: exactly 3 succeed, the 4th returns claim_limit_or_not_open.

// Verify normal single-claim flow still works:
const result = await claimRecommendation(openRecId);
// result.ok === true, result.value.id === openRecId

[vercel]

@anshul23102 is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[anshul23102]

This PR is ready for review. Both changed files have been tested against the reproduction steps in the issue description. Happy to make any adjustments based on your feedback.

[anshul23102]

Closing in favour of #224, which supersedes this with a cleaner implementation, proper unit tests, and a correct error-code distinction between claim_limit and already_claimed. All changes from this PR are included in #224.