Sync affiliate counts on application status changes

[morganschp]

Fixes #201.

Summary

• track the previous affiliate application status before approve/reject updates
• increment total_affiliates when an application becomes approved
• decrement total_affiliates when an approved application is rejected, clamped at zero
• add focused PATCH route tests for increment, decrement, clamping, and no-op same-status transitions

Validation

• ./node_modules/.bin/vitest run src/app/api/affiliates/offers/[id]/applications/route.test.ts
• ./node_modules/.bin/eslint src/app/api/affiliates/offers/[id]/applications/route.ts src/app/api/affiliates/offers/[id]/applications/route.test.ts
• ./node_modules/.bin/prettier --check src/app/api/affiliates/offers/[id]/applications/route.ts src/app/api/affiliates/offers/[id]/applications/route.test.ts
• ./node_modules/.bin/tsc --noEmit --pretty false
• git diff --check -- src/app/api/affiliates/offers/[id]/applications/route.ts src/app/api/affiliates/offers/[id]/applications/route.test.ts

[greptile-apps]

Greptile Summary

This PR adds total_affiliates counter synchronisation to the affiliate application approve/reject flow. It introduces a helper updateAffiliateCountForStatusChange that computes a delta based on the previous and next status, then applies it to the offer row, and adds a focused test suite covering increment, decrement, clamp-at-zero, and no-op transitions.

• The PATCH handler now fetches the application's current status before writing the update, so the delta can be computed correctly; both a decrement and an early-return no-op path are covered.
• total_affiliates was added to the GET handler's offer select but is still absent from the PATCH handler's offer select (line 105), meaning offer.total_affiliates is always undefined in production and the counter resets to 0 or 1 on every action — the previous review comment on this remains unaddressed.
• The count update runs after the application row has already been mutated and only logs a warning on failure, leaving the counter silently out of sync if the update fails.

Confidence Score: 3/5

Not safe to merge: the offer select in the PATCH handler still omits total_affiliates, so the counter will be set to 0 or 1 on every approve/reject regardless of its real value.

The PATCH handler reads the offer row with .select("id, seller_id") (line 105), leaving total_affiliates out. Every call to updateAffiliateCountForStatusChange therefore receives undefined as currentCount, which the || 0 fallback silently converts to 0 — so every approval writes 1 and every rejection writes 0, permanently destroying the real counter. This bug was noted in the previous review pass and is still present in the current diff.

route.ts line 105 — the offer select must include total_affiliates before this change can function correctly

Important Files Changed

Filename	Overview
src/app/api/affiliates/offers/[id]/applications/route.ts	Adds updateAffiliateCountForStatusChange helper and pre-fetch of existingApplication, but the PATCH offer select still omits total_affiliates so the helper always receives undefined and miscounts
src/app/api/affiliates/offers/[id]/applications/route.test.ts	New test file covering increment/decrement/clamp/no-op paths; mock always returns total_affiliates regardless of the select columns actually used, masking the production mis-select

_{Reviews (3): Last reviewed commit: "Sync affiliate count on application stat..." | Re-trigger Greptile}

[greptile-apps]

Read-modify-write race on total_affiliates

Two concurrent PATCH requests that both approve different applications for the same offer will both read the same total_affiliates snapshot, compute count + 1 independently, and both write the same resulting value — so one increment is silently lost. A database-level atomic update (e.g. a Postgres total_affiliates + 1 expression or an RPC with FOR UPDATE row lock) would eliminate this window.

[greptile-apps]

Mock returns total_affiliates regardless of the select fields, masking the production bug

mockPatchQueries always includes total_affiliates in the offer data no matter what columns are actually selected by the route. As a result all four tests pass even when the route's offer query omits total_affiliates, giving a false green signal. Tightening the mock (e.g. by only returning fields that match the select string, or by adding an assertion that the select call includes total_affiliates) would let the test suite catch this class of regression.