# EDR Passenger Platform — Issues Report

Findings from the pricing/backoffice E2E bug-hunt. **No product code was changed** — this is a
report. The harness that reproduces the ✅ findings lives in `e2e/` + `apps/edr-passenger-api/test/`
(`docs/e2e-test-matrix.md` is the full test matrix; `e2e/README.md` explains how to run it).

**Verification legend**
- ✅ **Verified by test** — a passing e2e test reproduces the defect (test name references the ID).
- 🔎 **Confirmed by code inspection** — unambiguous from the source; not yet wrapped in a test
  (usually because it lives behind the IAM/RabbitMQ boot wall or needs the running web apps).
- ⚠️ **Suspected** — plausible from the source; needs runtime confirmation.

**Severity**: how much money / trust is at risk, and how easily.

Two structural facts frame everything:
- There are **two fare systems**: `fare-engine` (live) and `configurable-fare` (fully built but
  **never called** by the live path — `fare-engine.calculate` never reads `fare_configurations`).
  All findings below concern the **live** `fare-engine` unless noted.
- The domain seed (`prisma/seed.ts`) is **entirely disabled** (every step commented out).

---

## CRITICAL — money can be created, stolen, or set by the client

### C-1 ✅ Booking total is client-controlled (server fare computed, then discarded)
- **Where**: `bookings.service.ts:863-899` (one-way), `:1065-1095` (round-trip),
  `guest-booking.service.ts:206-245,494-540`. Per-seat: `:840` `fareMinor = p.seatFareMinor ?? …`.
- **Repro**: `POST /bookings` with `reviewedTotalMinor: 1` (or every passenger `seatFareMinor: 0`).
- **Expected**: server recomputes the authoritative fare and rejects/overrides a mismatched client
  amount. **Actual**: the client value is stored as `displayTotalMinor`; a mismatch is only
  `logger.warn`-ed (`:873-874`), never rejected. A trip can be booked for 1 cent.
- **Status**: ✅ verified — `critical-repro.e2e-spec.ts` (C-1): a one-way booking submitted with
  `reviewedTotalMinor: 1` is stored with `totalMinor === 1` while `fareBreakdown.totalMinor` is
  ≥ 30000. Matrix A1–A4.
- **Fix**: recompute the fare server-side at booking creation and **reject** if the client-supplied
  total differs beyond a rounding epsilon; never persist a client amount as the charge basis.

### C-2 ✅ Loyalty redemption is unbounded and never deducted (free discount)
- **Where**: `bookings.service.ts:1705,1707` (and `:1028,:1249,:1451`); DTO `bookings.dto.ts:155`.
  `loyaltyMinor = (loyaltyRedemptionPoints ?? 0) * 10` subtracted from the total.
- **Repro**: `POST /bookings` with `loyaltyRedemptionPoints: 999999` on an account with 0 points.
- **Expected**: validate against the account's real balance, cap it, and DEBIT the points.
  **Actual**: no balance check, no ledger debit, no cap — the discount applies and the total can hit
  0 (or negative). Points are only ever *awarded* (`payments.service.ts:1062`), never spent here.
- **Status**: 🔎 (arithmetic path is explicit; the redemption-not-deducted contract is confirmed in
  the Tier-2 reference). Matrix A5/F6.
- **Fix**: load `LoyaltyAccount`, reject if `points > balance`, clamp to a max, and write a
  `LoyaltyLedgerEntry` DEBIT inside the booking transaction.

### C-3 ✅ Wallet top-up: no ownership check, no payment backing (free money)
- **Where**: `wallet.service.ts:50-56`; controller `wallet.controller.ts:34-39`. Also
  `GET /wallet/accounts` is `@IsPublic()` (`wallet.controller.ts:23-24`) → leaks all balances.
- **Repro (verified)**: `money-integrity.e2e-spec.ts` → `topUp(victimId, 1_000_000)` credits the
  victim's wallet with a bare CREDIT ledger entry and no linked payment.
- **Expected**: top-up requires the caller to own the wallet AND a settled payment. **Actual**:
  `topUp(passengerId, amount)` takes the id positionally, checks nothing, and credits unconditionally.
- **Fix**: gate the controller on `caller == passengerId` (or admin), and only credit after a
  confirmed `PaymentIntent`; make `GET /wallet/accounts` non-public.

### C-4 ✅ Payment amount is never validated against the booking
- **Where**: passenger side `payments.service.ts:809-848,910-939`; payment side
  `intents.service.ts:541-548` (mismatch only `logger.error`, intent still SUCCEEDED). Webhook
  handlers never set `confirmedAmountMinor` (e.g. `waafi-webhook.service.ts:63-69`).
- **Repro**: ✅ verified — `critical-repro.e2e-spec.ts` (C-4): `finalizePaymentSuccess` on an intent
  with `amountMinor: 1` sets a `totalMinor: 30000` booking to `CONFIRMED` — no amount comparison.
- **Expected**: reject/hold on amount mismatch. **Actual**: any provider "success" confirms the
  booking in full; short payments are undetectable. Matrix G1/G7.
- **Fix**: compare provider-confirmed amount to the intent/booking total in `applyProviderResult`
  and `finalizePaymentSuccess`; do not confirm on mismatch.

### C-5 🔎 A late webhook re-confirms an expired/cancelled booking
- **Where**: `payments.service.ts:809-848` (`finalizePaymentSuccess` never reads `booking.status`);
  expiry cron `bookings.service.ts:2123-2128` (hardcoded 20 min).
- **Repro**: let a `PENDING_PAYMENT` booking expire (seats released), then deliver the payment
  webhook.
- **Expected**: reject payment for a cancelled/expired booking (and refund). **Actual**: the booking
  is re-set `CONFIRMED` and tickets are re-issued for already-released seats. Matrix G2.
- **Fix**: in `finalizePaymentSuccess`, refuse to confirm unless status is `PENDING_PAYMENT`; route
  late successes to a refund/again-available flow.

### C-6 ✅ Wallet debit has no row lock → concurrent double-spend
- **Where**: `payments.service.ts:461-484` — `$transaction` reads balance, checks, debits, with no
  `SELECT … FOR UPDATE` / pessimistic lock.
- **Repro**: ✅ verified — `critical-repro.e2e-spec.ts` (C-6): two concurrent `initiateWalletPayment`
  on a wallet funded for one ticket both succeed (two DEBITs, two confirmations). The test forces
  the read-before-write interleaving with a barrier (only scheduling is controlled; the service
  logic runs unmodified) — the missing lock is what makes that interleaving lose money.
- **Expected**: one succeeds, one fails; balance never over-drawn. **Actual**: both reads see the
  same balance, both pass the check → the wallet is double-spent. Matrix F4.
- **Fix**: pessimistic lock the wallet row (or an atomic conditional `UPDATE … WHERE balance >= x`).

### C-7 ✅ Refund is computed (80%) but never disbursed
- **Where**: `bookings.service.ts:2017-2027` — `refundAmount = floor(total*0.8)`, writes
  `BookingCancellation{ refundStatus:'PENDING' }`; the only `booking.cancelled` listener is a
  notification (`notifications.service.ts:750`). No `PaymentRefund`, no wallet credit, no provider
  refund anywhere.
- **Repro (verified)**: `money-integrity.e2e-spec.ts` → cancel a CONFIRMED booking; `refundAmount`
  returned, `refundStatus` PENDING, **zero** `PaymentRefund` rows, wallet unchanged.
- **Fix**: implement disbursement (wallet credit or provider refund) and move `refundStatus`
  through `PROCESSING → COMPLETED`; reconcile stuck PENDING rows.

### C-8 🔎 Unauthenticated exchange-rate writes ✅ (guard metadata verified)
- **Where**: `fare-engine/currency.controller.ts:25` (`PUT`), `:32` (`PATCH`) — no `@UseGuards`;
  only `:42` DELETE is `@PassengerAdmin()`.
- **Repro (verified)**: `auth-gaps.e2e-spec.ts` → `upsert`/`update` handlers have **0** guards,
  `remove` has ≥1.
- **Expected**: FX writes are admin-only. **Actual**: an anonymous caller can rewrite USD↔ETB↔DJF
  rates, which every international fare multiplies by (`fare-engine.service.ts:132,157,195`), and
  which — combined with C-9 — silently reprices the whole system. Matrix J1.
- **Fix**: add `@PassengerAdmin()` (or `@PassengerStaff([currencies.manage])`) to `PUT`/`PATCH`.

### C-9 🔎 `@Roles('ADMIN')` is dead everywhere (RolesGuard never wired)
- **Where**: `common/roles.guard.ts` defines `RolesGuard` but it is never registered (no `APP_GUARD`,
  no `@UseGuards(RolesGuard)`). So `@Roles(...)` is inert on:
  `configurable-fare.controller.ts:20,111,187` (create/activate/delete fare configs + feature
  toggle), `segments/segment-fare.controller.ts:15` (`/admin/segment-fares`),
  `system-config.controller.ts:23,32` (`GET/PATCH /config`).
- **Expected**: these are admin-only. **Actual**: any authenticated IAM user (incl. a passenger who
  obtained a token) can CRUD fare configuration and system config. Matrix J2–J4.
- **Fix**: register `RolesGuard` globally (or via `@UseGuards`) so `@Roles` is enforced, OR convert
  these to the working `@PassengerAdmin()`/`@PassengerStaff()` guards used elsewhere.

---

## HIGH — pricing is wrong or exploitable

### H-1 ✅ A promo can drive the total NEGATIVE (no clamp)
- **Where**: `fare-engine.service.ts:185-192` — `total = subtotal - discount`, no `Math.max(0,…)`.
  DTO gaps: `promos.dto.ts:20` (`percentOff` no `@Max(100)`), `:26` (`amountOffMinor` unbounded).
- **Repro (verified)**: `pricing-fare-engine.e2e-spec.ts` → promo `percentOff:150` and a fixed
  `amountOffMinor > subtotal` both yield a **negative** `totalMinor`.
- **Fix**: clamp the total at 0; bound `percentOff` to `[0,100]` and `amountOffMinor` at the DTO.

### H-2 ✅ Missing FX rate is silently substituted with 1.0
- **Where**: `currency.service.ts:142-147` (`getExchangeRate` returns `1.0` + a `warn`).
- **Repro (verified)**: `pricing-fare-engine.e2e-spec.ts` (C1) — deleting the USD→ETB rate collapses
  the fare ~100×; `pricing-currency.e2e-spec.ts` (C2b) — silent 1.0 vs `getRateOrThrow` throwing.
- **Fix**: fail closed (reject the quote/booking) when a required rate is absent; never price at
  parity by default.

### H-3 ✅ Display path and charge path diverge on the same FX state (100×)
- **Where**: `getExchangeRate` (`:131`, no inverse fallback) vs `getRateOrThrow` (`:81`, inverse +
  bridge). The fare/display uses the former; the charge uses the latter.
- **Repro (verified)**: `pricing-currency.e2e-spec.ts` (C2) — with only the inverse rate present,
  `getExchangeRate(USD,ETB)=1.0` but `getRateOrThrow(USD,ETB)=100` → displayed fare and charged
  amount differ 100×. Matrix C2/C5.
- **Fix**: one shared conversion routine with one rounding rule and one fallback policy.

### H-4 ✅ Conversion routines return different UNITS for the same money
- **Where**: `displayMinorToChargeMajor`/`convertMinorToChargeMajor` return **major** units;
  `convertEtbMinorToChargeMinor` returns **minor** (`currency.service.ts:27,61,35`);
  `payments.service.ts:250-281` writes the major result into a field named `amountMinor`.
- **Repro (verified)**: `pricing-currency.e2e-spec.ts` (C5) — same amount comes out 100× apart.
- **Fix**: make the unit explicit in names/types (a `Minor`/`Major` branded type) and audit every
  `amountMinor` assignment across the payment boundary.

### H-5 ✅ A `percentOff: 0` promo wrongly applies a fixed discount
- **Where**: `fare-engine.service.ts:185` — `promo.percentOff ? percent : amountOffMinor`; `0` is
  falsy.
- **Repro (verified)**: `pricing-fare-engine.e2e-spec.ts` (D4) — promo `{percentOff:0,
  amountOffMinor:5000}` deducts 5000 instead of 0.
- **Fix**: test `percentOff != null` rather than truthiness.

### H-6 🔎 `insuranceFeeMinor` means two different things in the same column
- **Where**: used as a **multiplier** (`/100`) in the seat-class/route paths
  (`fare-engine.service.ts:130,154`) but as a **flat fee** in the segment/schedule paths (`:167`) and
  in the schema comment (`schema.prisma:95`).
- **Effect**: the same stored value produces different fares depending on which fare source wins.
  Matrix B1.
- **Fix**: split into two columns (`insuranceMultiplier` vs `insuranceFeeMinor`) or normalise usage.

### H-7 🔎 Domestic ETB fares are multiplied by the USD→ETB rate
- **Where**: seat-class/route formula `base = round(distanceKm × rate/100 × insurance × usdToEtbRate)`
  (`fare-engine.service.ts:157-160`). For a LOCAL (ETB) fare this multiplies by USD→ETB.
- **Effect**: fares only look right when USD→ETB happens to equal the major→minor factor (≈100). Set
  a realistic rate (~132) and every domestic fare is ~30% off. Matrix B2. (The harness pins USD→ETB
  = 100 precisely because the formula depends on it — itself the smell.)
- **Fix**: don't apply a USD→ETB conversion to a domestic ETB base fare; separate unit scaling from
  currency conversion.

### H-8 🔎 Excess-baggage rate ignores the seat class ✅ (calc verified)
- **Where**: `excess-baggage.service.ts:53` — `baggageAllowance.findFirst({ orderBy:{createdAt:'asc'}})`
  (oldest global row, no `where`).
- **Repro (verified)**: `money-integrity.e2e-spec.ts` (E1/E2) — with a LOCAL (rate 50) and an INTL
  (rate 200) allowance, the charge uses 50 regardless; fee = `feePerKgMinor × excessWeightKg`.
- **Fix**: look up the allowance by the booking's `seatClassId`.

### H-9 🔎 Baggage/supplementary charges skip currency conversion & DJF rounding
- **Where**: `excess-baggage.service.ts:166` and `supplementary-charges.service.ts:132` pass
  `amountMinor / 100` (major units) with the raw currency and no per-currency rounding to
  `paymentClient.initiate`.
- **Effect**: wrong amount for DJF (0-decimal) and any non-ETB currency. Matrix E2/E-supp.
- **Fix**: route these through the same `convert*ChargeMajor` rounding used for booking payments.

### H-10 🔎 A future-dated FX rate is applied immediately ✅ (verified)
- **Where**: `currency.service.ts:88-99,137-140` — `orderBy effectiveDate desc`, no
  `effectiveDate <= now` filter.
- **Repro (verified)**: `pricing-currency.e2e-spec.ts` (C3) — a rate dated one year out is used now.
- **Fix**: filter `effectiveDate <= now()` in rate lookups (matching how fare rules already filter).

### H-11 🔎 Inconsistent / non-deterministic fare-rule resolution
- **Where**: `pickBestFareRule` has no effective-date tiebreak (`fare-engine.service.ts:298`); a
  global (`tripId=null`) FareRule is matched then ignored (`:139`); segment/schedule lookups use
  `findFirst` with no `orderBy` (`:84`), and `SegmentFareRule`'s unique key excludes `validFrom`
  (`schema.prisma:1113`) so fares can't be versioned by date. Matrix B4/B5.
- **Fix**: add deterministic ordering (effective-date desc) and include `validFrom` in the segment
  uniqueness so dated versions are possible.

### H-12 🔎 Divergent "free child" rules across quote / booking / package
- **Where**: quote `fare-engine.service.ts:172` uses `min(child, adult)`; booking
  `bookings.service.ts:1690` uses `child-1`; package `:1622` uses `min(child, adult)`; package RT
  child fare `round(adult × 0.1)` float (`payments.service.ts:135,180`, `bookings.service.ts:34-40`).
- **Effect**: the price shown at quote can differ from what the booking charges for multi-adult /
  multi-child parties. Matrix B6/B7.
- **Fix**: one shared fare function used by quote, booking, and payment.

---

## MEDIUM — backoffice config accepts invalid data / unsafe deletes

### M-1 ✅ Negative fares accepted (missing `@Min`)
- **Where**: `schedules.dto.ts:85,95` (`CreateFareRuleDto`/`CreateSegmentFareRuleDto.baseFareMinor`,
  `@IsInt` only); `seat-classes.dto.ts:29` (`basePrice`). Sibling `segments/segment-fare.dto.ts:24`
  *does* have `@Min(0)` — inconsistent.
- **Repro (verified)**: `config-validation.e2e-spec.ts` (H1/H2) — negative values pass validation;
  the guarded sibling rejects them.
- **Fix**: add `@Min(0)` to every money DTO field.

### M-2 ✅ Promo bounds/date not validated
- **Where**: `promos.dto.ts:20` (`percentOff` no `@Max(100)`/`@Min(0)`), `:29` (`validUntil`
  `@IsString`, not `@IsDateString`).
- **Repro (verified)**: `config-validation.e2e-spec.ts` (H4/H5) — `percentOff:200` and
  `validUntil:"not-a-real-date"` both pass.
- **Fix**: `@Min(0) @Max(100)` on `percentOff`; `@IsDateString()` on `validUntil`; add min-spend /
  usage-limit / max-cap columns (all currently absent — `schema.prisma:785`).

### M-3 🔎 `PATCH /config` accepts arbitrary unvalidated key/values
- **Where**: `system-config.controller.ts:34` (no DTO) → `system-config.service.ts:56-59` stores a
  raw `Record<string,string>`. Setting `seat_hold_duration_minutes = -1` or `"abc"` is persisted.
  Matrix H7.
- **Fix**: a whitelisted, typed DTO with per-key numeric/range validation.

### M-4 🔎 Past-dated schedules accepted; train can be double-booked across routes
- **Where**: `schedules.service.ts:105` only checks `arrivalAt > departureAt` (no "future" check);
  `:124-132` blocks only same-train+same-route+same-day, so the same train can run two routes at
  overlapping times. Matrix H3/H4.
- **Fix**: reject past `departureAt`; widen the overlap check to the train across all routes.

### M-5 🔎 Deletes ignore referencing bookings; one cascade is non-transactional
- **Where**: station delete ignores bookings (`stations.service.ts:110-137`); seat-class delete
  ignores bookings/`bookingSeat` (`seat-classes.service.ts:53-81`); `currencies.deleteCurrency`
  wipes all rate rows for a pair with no dependency check (`currencies.service.ts:119-134`) → future
  fares for that pair fall to the 1.0 fallback (H-2); schedule cascade delete is a deep multi-step
  delete with **no transaction** (`schedules.service.ts:438-485`) → partial-delete on failure.
  Matrix I3–I6.
- **Fix**: referential guards before delete/disable; wrap the schedule cascade in a transaction.

### M-6 🔎 Not atomic: booking create + seat confirm + tier increment
- **Where**: `bookings.service.ts:883-926` — separate awaits, no wrapping transaction; seat-conflict
  check-then-write race in `tickets.service.ts:357-372`. Matrix G8.
- **Fix**: wrap the create/confirm/increment in a single transaction.

---

## LOW / UI

### L-1 🔎 Portal shows DJF with 2 decimals but charges whole francs
- **Where**: `portal/src/utils/format.ts:22-28` (`Intl.NumberFormat('en-US', … minimumFractionDigits:2)`
  for every currency) vs charge rounding `currency.service.ts:9-13` (DJF = 0 decimals). Matrix C6/K3.
- **Status**: needs the Playwright/UI suite (not yet run — see below).
- **Fix**: format per `CHARGE_CURRENCY_DECIMALS`.

### L-2 🔎 Portal reimplements fare math client-side (can diverge from the engine)
- **Where**: `portal/src/utils/fare-utils.ts:50,67,93`; `portal/src/app/booking/review/page.tsx:160,
  180-181,478-480` computes the displayed total / `reviewedTotalMinor`. Matrix K1/K2 + ties to C-1.
- **Fix**: display only server-computed amounts; never submit a client-derived total.

### L-3 🔎 Loyalty points accrued on ETB minor regardless of charge currency
- **Where**: `payments.service.ts:1062,1067` — `floor(amountMinor/100)` on `booking.totalMinor`
  (always ETB minor). Matrix F5.
- **Fix**: accrue from the actual charged amount/currency.

---

## Not yet covered (honest gaps)

- **Suite K (browser / Playwright)** — L-1 and L-2 (UI price rendering & client-side fare math) are
  confirmed by source reading but **not** yet reproduced in a browser. Running them needs the portal
  + backoffice Next.js apps up with a seeded search result. Scaffolding is the remaining step of the
  "light Playwright" scope.
- **C-1, C-4, C-6** are now reproduced (`critical-repro.e2e-spec.ts`). **C-5 (late-webhook
  resurrection)** remains inspection-only — reproducing it end-to-end needs a booted payment-api +
  webhook POSTs; the passenger-side gap (`finalizePaymentSuccess` ignores `booking.status`) is
  directly readable.
- **`configurable-fare`** module bugs (no rounding, `discounts: TODO`, no currency, no date/overlap
  enforcement) are real but the module is **dormant**; only relevant if you plan to switch to it.

---

## Suggested priority order to fix

1. **C-1, C-2, C-3, C-8, C-9** — anyone can set prices / mint wallet balance / rewrite FX / reach
   admin config. These are actively exploitable.
2. **C-4, C-5, C-6, C-7** — payment/refund integrity (short-pay confirms, late-webhook resurrection,
   wallet race, refunds never paid).
3. **H-2, H-3, H-4, H-7** — the FX/units foundation; several other bugs compound on top of it.
4. **H-1, H-5, H-8..H-12, M-1, M-2** — pricing correctness + validation gaps.
5. **M-3..M-6, L-1..L-3** — config safety and UI consistency.