Validate affiliate conversion sat amounts

[absalonCRC]

Summary

• fixes bug: affiliate conversions accept fractional sat amounts #139
• rejects fractional sale_amount_sats values when creating manual affiliate conversions
• rejects fractional sale_amount_sats values before recalculating edited conversions
• adds regression coverage for fractional create and update requests

Why

Satoshi amounts are indivisible. Allowing decimal sale amounts can store impossible conversion values and feed fractional inputs into commission calculation.

Validation

• pnpm test:run src/app/api/affiliates/offers/[id]/conversions/route.test.ts
• pnpm exec eslint src/app/api/affiliates/offers/[id]/conversions/route.ts src/app/api/affiliates/offers/[id]/conversions/route.test.ts
• pnpm type-check
• git diff --check

Payment for the active uGig affiliate testing bounty can go to SOL: 27sdMYXofqoM9qR13bZhccRNYeEgYn5EoHXTSJn4QWKP.

Payment fallback: PayPal cultofrozen@gmail.com

[greptile-apps]

Greptile Summary

This PR tightens sale_amount_sats validation so satoshi amounts must be positive integers, rejecting fractional values in both the POST (create) and PUT (edit) conversion endpoints. The isPositiveIntegerSats helper centralises the check using Number.isInteger, and the PUT path is upgraded from silently ignoring an invalid sale_amount_sats to returning a 400 error.

• POST: replaces the loose > 0 number check with isPositiveIntegerSats, updating the error message to "must be a positive integer".
• PUT: adds an early-return guard before commission recalculation so any present but non-integer sale_amount_sats (fractional, string, boolean, null) is now rejected with a 400 rather than silently skipped.
• Tests: two new regression cases cover 100.5 for both POST and PUT, asserting calculateCommission is never reached on invalid input.

Confidence Score: 4/5

Safe to merge; the validation logic is correct and the new tests confirm both the POST and PUT rejection paths work as intended.

The isPositiveIntegerSats guard is sound (Number.isInteger correctly handles fractions, NaN, and Infinity), and the early-return placement in PUT ensures commission recalculation is never reached on bad input. One behaviour change worth awareness: the PUT endpoint previously silently ignored a non-number sale_amount_sats (e.g. a string or null), but will now return a 400 for any defined, non-integer value — existing clients relying on the silent-ignore path would start receiving errors. No other functional concerns found.

No files require special attention; both changed files are straightforward and well-tested.

Important Files Changed

Filename	Overview
src/app/api/affiliates/offers/[id]/conversions/route.ts	Adds isPositiveIntegerSats helper and applies it to both POST and PUT handlers; removes silent-ignore behavior in PUT so non-integer sale_amount_sats now returns 400 instead of being skipped.
src/app/api/affiliates/offers/[id]/conversions/route.test.ts	Imports PUT, adds mockCalculateCommission, and adds two new regression tests — one for fractional POST (100.5) and one for fractional PUT — both asserting a 400 with the updated error message.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[POST or PUT request] --> B{sale_amount_sats\nprovided?}
    B -- "PUT: undefined" --> C[Skip sat validation]
    B -- "present" --> D{isPositiveIntegerSats?}
    D -- "typeof !== number\n|| not integer\n|| <= 0" --> E[400: must be a positive integer]
    D -- "positive integer ✓" --> F{POST or PUT?}
    F -- POST --> G[recordConversion]
    F -- PUT --> H[calculateCommission\nthen DB update]
    C --> I{Other fields\nto update?}
    I -- "note / status" --> H
    I -- "none" --> J[400: Nothing to update]

Loading

_{Reviews (1): Last reviewed commit: "Validate affiliate conversion sat amount..." | Re-trigger Greptile}