Validate affiliate offer text update types

[rissrice2105-agent]

Fixes #451.

What changed

• Rejects non-string title values before trimming.
• Rejects non-string description values before trimming.
• Adds regression tests to confirm malformed values return 400 instead of falling through to a 500.

Validation

• ./node_modules/.bin/vitest.cmd run src/app/api/affiliates/offers/[id]/route.test.ts
• ./node_modules/.bin/tsc.cmd --noEmit

[greptile-apps]

Greptile Summary

This PR fixes a crash-on-invalid-input bug in the affiliate offer PATCH handler. Before the change, sending a non-string value for title or description would call .trim() on a non-string, throwing a TypeError that the outer catch block converted to a 500. The fix adds explicit typeof guards that return a 400 before touching those fields.

• route.ts: Adds typeof body.title !== \"string\" and typeof body.description !== \"string\" guards, mirroring the existing product_url guard pattern.
• route.test.ts: Adds two regression tests confirming that an object ({ text: \"…\" }) for title and an array for description each produce a 400 with the expected error message.

Confidence Score: 4/5

Safe to merge — the validation guards are correct and narrowly scoped, and the tests exercise exactly the crash path being fixed.

The two new guards are correct and follow the existing product_url pattern. The only gap is that several other text fields (promo_text, product_type, category, tags) still have no type-guards, which leaves a small inconsistency now that the most visible fields are hardened.

Lines 125–136 of route.ts where the remaining unguarded fields are assigned; consider extending the same pattern there.

Important Files Changed

Filename	Overview
src/app/api/affiliates/offers/[id]/route.ts	Adds type-guards for title and description before calling .trim(), returning 400 instead of a 500 TypeError for non-string inputs.
src/app/api/affiliates/offers/[id]/route.test.ts	Adds two regression tests that confirm object and array values for title/description return 400 rather than falling through to a 500.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[PATCH /api/affiliates/offers/id] --> B{Auth check}
    B -- Unauthorized --> C[401]
    B -- Authorized --> D{Ownership check}
    D -- Not owner --> E[404]
    D -- Owner --> F{body.title defined?}
    F -- Yes --> G{typeof title === string?}
    G -- No --> H[400 title must be a string]
    G -- Yes --> I[updateData.title = title.trim]
    F -- No --> J{body.description defined?}
    I --> J
    J -- Yes --> K{typeof description === string?}
    K -- No --> L[400 description must be a string]
    K -- Yes --> M[updateData.description = description.trim]
    J -- No --> N{body.product_url defined?}
    M --> N
    N -- Yes --> O{product_url !== null AND not string?}
    O -- Yes --> P[400 product_url must be a string]
    O -- No --> Q{isValidUrl check}
    Q -- Fails --> R[400 invalid scheme]
    Q -- Passes --> S[updateData.product_url = url]
    N -- No --> T[Apply remaining fields and DB update]
    S --> T
    T --> U{DB error?}
    U -- Yes --> V[400 DB error]
    U -- No --> W[200 offer]

Loading

Comments Outside Diff (1)

1. src/app/api/affiliates/offers/[id]/route.ts, line 125-136 (link)

   Other text fields still unguarded against non-string inputs

   Fields like promo_text, product_type, category, and tags are passed straight into updateData without type-checking. If a caller sends an object or array for any of these, the DB driver or Supabase may silently coerce the value or the outer catch will convert the TypeError into a 500. This is a pre-existing gap, but now that title and description are hardened, the remaining fields stand out as inconsistent.

_{Reviews (1): Last reviewed commit: "Validate affiliate offer text update typ..." | Re-trigger Greptile}

[rissrice2105-agent]

CI is green for PR #452.

Verification:

• vitest run src/app/api/affiliates/offers/[id]/route.test.ts
• tsc --noEmit

uGig invoice evidence has been sent for this PR.