No Test for the Idempotency-Key UUID Validation Rejection

[therealjhay]

Category: Testing & Quality
Difficulty: High

Description:
The CreatePaymentBody Zod schema validates idempotencyKey as IdempotencyKeySchema = z.string().uuid(). If a non-UUID value is passed (e.g., "not-a-uuid"), the handler at line 618 calls CreatePaymentBody.parse(request.body) which will throw a ZodError caught by the global error handler, returning a 400 VALIDATION_ERROR. However, there is no test that verifies:

• A non-UUID idempotency key returns 400 with VALIDATION_ERROR code
• A UUID idempotency key longer than 255 characters is rejected (line 623–625)
• A valid UUID key passes through to the idempotency check
• A key that is exactly null or an empty string is treated as "no key provided"

The payment-idempotency.test.ts file rebuilds its own idempotency logic and does not test the Zod validation.

Location:
services/api-gateway/src/index.ts:617–625, shared/validation/schemas.ts:258–259

Acceptance Criteria:

• Write integration tests for all idempotency key validation scenarios using the real gateway handlers
• Test UUID validation: pass idempotencyKey: "not-a-uuid", expect 400
• Test length validation: pass a UUID that is 256+ chars, expect 400
• Test missing key: omit idempotencyKey, confirm payment is created without idempotency
• Test max length constant: verify IDEMPOTENCY_KEY_MAX_LEN (255) matches the Prisma schema's implicit String? limit

Technical Notes:

• Generate a 256-char string: 'a'.repeat(256).
• An empty string key should be treated the same as missing key (the trim() check at line 129).

[Sundayabel222]

I am writing to submit my application to resolve the issue: No Test for the Idempotency-Key UUID Validation Rejection.

Validating that our system successfully processes correctly formatted unique keys is only half the battle. To ensure absolute data integrity and catch client integration bugs early, our validation layers must strictly reject malformed data. If a client submits a corrupted string, a blank space, or an arbitrary non-UUID token as their idempotency key, the system should catch it immediately at the boundary and reject the request with a clean, structured validation error before it ever reaches our database queries or settlement engines.

[davidacunalopez]

Hello, my name is David Acuña, full stack developer. I checked this issue and I'd like to work on it. This is what I'll do:

I will add integration-style tests that exercise the real validation path: CreatePaymentBody Zod parsing (non-UUID body idempotencyKey → 400 VALIDATION_ERROR), the gateway Idempotency-Key header length check ('a'.repeat(256) → 400), omitted/empty keys treated as no idempotency, and a valid UUID body key accepted by the schema. I will also assert IDEMPOTENCY_KEY_MAX_LEN is 255 and document that this is the application-enforced limit (Prisma String? does not imply a 255-char DB limit).

I will wire these through a Fastify app using registerErrorHandler and the same parse/header checks as the real payment handler, rather than only the mirrored logic in the existing payment-idempotency.test.ts.

[grantfox-oss]

🦊 GrantFox — @Sundayabel222 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #244)
2. Your PR will be reviewed by the Betta-Pay maintainers

Good luck! Track your progress on GrantFox.