fix(listings): reject non-UUID path ids with 400 instead of 500

[jakubretajczykBD]

Summary

• Three ListingsController routes (GET /listings/offer-mappings/:id, GET /listings/marketplace-offer/:id, GET /listings/.../offer-creation-status/:connectionId/:offerCreationRecordId) forwarded a raw path param straight into a Postgres uuid-column lookup. A malformed id surfaced as an uncaught QueryFailedError and a 500 instead of a proper validation error.
• Added ParseUUIDPipe at the controller boundary so a malformed id now returns 400 Bad Request.
• As defense-in-depth, OfferMappingRepository.findById and OfferCreationRecordRepository.findById / updateStatus now catch driver error code 22P02 (invalid input syntax for uuid) and return null / throw OfferCreationRecordNotFoundException instead of leaking the infrastructure error — mirroring the existing ConnectionRepository pattern.

Related issues

Closes #1213

Test plan

• New listings-invalid-path-id.int-spec.ts — integration tests asserting 400 on all three routes for an invalid UUID
• New repository unit tests (offer-mapping.repository.spec.ts, offer-creation-record.repository.spec.ts) covering the 22P02 handling
• pnpm lint && pnpm type-check && pnpm test

Quality gate

• pnpm lint passes (zero errors)
• pnpm type-check passes (zero errors)
• pnpm test passes (all unit tests green)
• Optional, Docker required: pnpm test:integration passes — needed
  only if you touched apps/api/test/integration/** or any plugin's
  infrastructure/adapters/.

---

_{By submitting this pull request, I confirm that my contributions
are made under the terms of the Apache License 2.0, and I
certify the Developer Certificate of Origin
by signing off my commits.}

[piotrswierzy]

Tech Lead Review — Approve (polish only)

Clean, tightly-scoped fix for the 500-on-malformed-uuid class. Two layers, both correct:

• Interface: ParseUUIDPipe on the three UUID path params — verified against the route decorators (@Get(':id'), @Get(':id/offer'), and offerCreationRecordId on the two-param creation-status route). Correctly leaves connectionId unguarded on the two-param route, since it's a JS string comparison, never a DB query.
• Infrastructure (defense-in-depth): repository guards mirror the ConnectionRepository precedent verbatim — same error instanceof QueryFailedError && 'code' in error && error.code === '22P02' check, findById → null, updateStatus → OfferCreationRecordNotFoundException (domain error thrown from the infra layer, no QueryFailedError escapes the port — matches engineering-standards § Error Handling).

Checks I ran:

• Precedent exists and matches (connection.repository.ts:48-60).
• Over-catch is bounded — both guarded where clauses filter one uuid column (id); entityType on the offer-mapping query is a hardcoded constant, not user input, so 22P02 can only come from id.
• Scope is complete: the other :connectionId listings routes resolve through ConnectionRepository, which already carries the 22P02 guard, so they were never in the 500 class.
• No any. Tests cover both the 22P02 → null/throw path and a re-throw-on-different-code regression guard, plus an int-spec exercising the real Nest pipe pipeline (400 on all three routes + 404 regressions).

Suggestions (non-blocking)

1. Add @ApiResponse({ status: 400, ... }) to the three fixed routes — they can now return 400 but Swagger doesn't document it (the plan's §8 already flagged this as worth including).
2. GET /listings/:id/offer int-spec asserts only the 400 case; getOfferMapping gets a matching 404 regression but getMarketplaceOffer doesn't. A one-line 404-on-valid-absent-UUID assertion would symmetrically lock the unchanged happy path.
3. Nit (negligible): option-less ParseUUIDPipe rejects UUIDs outside v1-5 (e.g. the nil UUID) that Postgres would accept, shifting such nonsense input 404 → 400. Theoretical only — real ids are all v4.

Verdict: approve once out of draft and the quality gate (pnpm lint && pnpm type-check && pnpm test + the int-spec) is green in CI. Suggestions are optional polish.

[piotrswierzy]

Re-review (head 10fc1c8) — Approve

Re-reviewed after the branch went non-draft. The head moved fed8cdaf → 10fc1c8c only via a merge of main — git diff fed8cdaf..HEAD over the listings files is empty, so the controller and both repositories are byte-identical to the version I approved. No regression from the merge.

Verified

• ParseUUIDPipe placement — correct on getOfferMapping.id, getMarketplaceOffer.id, and getOfferCreationStatus.offerCreationRecordId. Leaving connectionId unguarded is right: it's only used for an in-memory equality check, never a DB lookup, so it can't raise 22P02. The int-spec documents this with an explicit 404-fall-through case.
• Repository 22P02 guards — no over-catch. The narrow error instanceof QueryFailedError && error.code === '22P02' check, plus the paired "re-throw a QueryFailedError with a different code" tests in both specs, positively prove non-target driver errors still propagate. Null-vs-throw split (read → null, mutate → OfferCreationRecordNotFoundException) matches the ConnectionRepository precedent.
• Tests — int-spec now also asserts the symmetric 404-on-valid-absent-UUID case for GET /listings/:id; unit specs cover both findById and updateStatus paths.

Non-blocking polish (carried over, optional)

1. The three UUID-guarded GET routes still lack @ApiResponse({ status: 400 }) (the two existing 400s are on updateOfferFields/createOffer). Doc-only.
2. GET /listings/:id/offer int-spec asserts only 400 — the symmetric 404 path is now covered by route 1.
3. ParseUUIDPipe accepts the nil UUID; harmless given the 400-not-500 goal.

Verdict: Approve. Fix is correct and unchanged; coverage is solid. None of the above blocks merge.