Fix partial bulk application status updates

[phucnguyen1707]

Summary

Fixes #484.

The bulk application status route now rejects a batch when any requested application ID is missing, instead of updating the subset Supabase returned and reporting success.

Verification

• npm test -- run src/app/api/applications/bulk-status/route.test.ts
• npm run type-check

[greptile-apps]

Greptile Summary

This PR fixes a silent partial-update bug in the bulk application status endpoint: previously, if any requested IDs were absent from the database, Supabase would silently update only the subset it found and return success. The fix adds a post-fetch ID reconciliation step that returns 404 when any requested ID is missing, preventing partial writes entirely.

• route.ts: After fetching applications, deduplicates the requested IDs, diffs them against the returned set, and short-circuits with 404 if any are absent — placed correctly before the ownership check and the UPDATE.
• route.test.ts: Adds a test that verifies the new 404 path and asserts that neither the UPDATE nor the notifications INSERT is called when an ID is missing.

Confidence Score: 4/5

Safe to merge; the fix is narrowly scoped and correctly prevents partial updates without touching any other behavior.

The new guard logic is correct and well-placed. The two minor observations — missing IDs not echoed in the 404 body, and the UPDATE still referencing the raw input array instead of the deduplicated set — do not affect correctness of the fix itself.

No files require special attention beyond the inline suggestions on route.ts.

Important Files Changed

Filename	Overview
src/app/api/applications/bulk-status/route.ts	Adds a post-fetch check that compares returned IDs against the requested set and returns 404 if any are missing; the logic is correct but the 404 body does not surface which IDs were absent, and the downstream UPDATE still uses the raw input array instead of the deduplicated set.
src/app/api/applications/bulk-status/route.test.ts	Adds one focused test covering the new partial-miss 404 path; success path, all-IDs-missing path, and authorization-failure path remain untested.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[PUT /api/applications/bulk-status] --> B{Auth valid?}
    B -- No --> C[401 Unauthorized]
    B -- Yes --> D{JSON valid?}
    D -- No --> E[400 Invalid JSON]
    D -- Yes --> F{Schema valid?}
    F -- No --> G[400 Validation error]
    F -- Yes --> H[SELECT applications WHERE id IN application_ids]
    H --> I{fetchError?}
    I -- Yes --> J[400 DB error]
    I -- No --> K{applications empty?}
    K -- Yes --> L[404 No applications found]
    K -- No --> M{Any IDs missing? - new check}
    M -- Yes --> N[404 Some applications were not found]
    M -- No --> O{All gigs owned by user?}
    O -- No --> P[403 Unauthorized gigs]
    O -- Yes --> Q[UPDATE applications SET status]
    Q --> R{updateError?}
    R -- Yes --> S[400 Update error]
    R -- No --> T[INSERT notifications]
    T --> U[200 updated count + applications]

Loading

Comments Outside Diff (1)

1. src/app/api/applications/bulk-status/route.ts, line 103-111 (link)

   The UPDATE at line 110 uses the original application_ids rather than the deduplicated requestedIds. While Postgres handles duplicate values in IN(...) correctly, using requestedIds consistently avoids sending unnecessary extra values to the database and keeps the intent clear.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "Fix partial bulk application updates" | Re-trigger Greptile}

[greptile-apps]

The 404 response tells the caller that some IDs were not found, but omits which ones. A client that receives this error has no way to distinguish a typo from a genuine access issue without re-querying; returning missingIds in the body makes retries and debugging straightforward.

Suggested change

	if (missingIds.length > 0) {
	return NextResponse.json(
	{ error: "Some applications were not found" },
	{ status: 404 }
	);
	}
	if (missingIds.length > 0) {
	return NextResponse.json(
	{ error: "Some applications were not found", missing_ids: missingIds },
	{ status: 404 }
	);
	}

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!