GEWIS / sudosos-backend / 31191558717

92%

develop: 92%

push

github

feat: emit terminal payment state changes over websocket (#1011)

A point of sale currently polls GET /terminal-payments/{id} every two seconds
to find out whether a payment finished, which floods the logs with controller
traces and makes the cashier wait out a poll interval after the customer has
already tapped.

Adds a terminal_payment:{id}:updates room and a terminal_payment:updated event
carrying the full TerminalPaymentResponse. Emitted when the payment is handed
to a reader, when the webhook settles it, and on cancellation from either the
explicit DELETE or Stripe.

Rooms are scoped to a single payment rather than to a point of sale because
cancelling detaches the temporary transaction and never sets a final one, so a
cancelled payment has no point of sale left to route an update by. Addressing
the payment directly mirrors how QR sessions already work.

Updates are emitted from the controllers, after their database transaction has
resolved, never from inside the services. A subscriber reacts to `paid` by
clearing the cart, so describing work that later rolls back would lose a sale.
That matters here because handleWebhookEvent swallows errors and lets its
transaction commit even when settlement failed halfway.

The relation check lives in a helper rather than using TerminalPaymentService,
which reaches TransactionService and back to WebSocketService. It loads the
entity with a dynamic import: the terminal entity subtree contains a mutual
import between tmp-sub-transaction and tmp-sub-transaction-row, and pulling it
in from the websocket layer at module load reorders initialisation enough that
TmpSubTransactionRow extends an undefined SubTransactionRow. The entity cycle
itself is worth fixing separately.

4444 of 5058 branches covered (87.86%)

Branch coverage included in aggregate %.

123 of 153 new or added lines in 7 files covered. (80.39%)

22633 of 24313 relevant lines covered (93.09%)

823.33 hits per line