feat(bookings): add event handlers for booking invoice payment processing
fix(bookings): include PAYMENT_VERIFICATION_IN_PROGRESS status in queries
fix(train-scheduling): update status checks to include PAYMENT_VERIFICATION_IN_PROGRESS
feat(notifier): notify customers when a train is cancelled
The suite drove a containerized freight API, so every code change needed an
image rebuild before a test could see it, and there was no way to attach a
debugger. Files also ran strictly in sequence against one shared database,
which is the root of the warm-stack gotchas the README documents: stowaway
paid bookings climbing back aboard, a short consist on the fifth file.
The freight app now boots inside each vitest worker from dist/, and each
worker owns a whole shard of the topology - its own database, payment API,
gateway mock and broker vhost - so nothing mutable is shared and files run
in parallel. Full suite drops from roughly 20 minutes to 196s at 4 shards.
- main.ts exports createFreightApp() so the harness applies the same prefix,
pipes, filters and interceptors as production instead of replaying them by
hand; self-start is guarded by require.main so the Dockerfile CMD still boots
- booking-window tick cadence is env-driven (BOOKING_WINDOW_TICK_CRON), */1 in
the suite, */10 unchanged in production
- prepare-shards.mjs seeds a template database (boot seeders, then the SQL
fixtures that depend on them) and clones it per shard; it.mjs re-clones on
every run, so each run is hermetic
- gateway mock and payment API are generated per shard: the mock keeps modes
and orders process-global and 20 of 25 specs reset it in beforeAll, and the
inbound CBE bill query has to reach one specific shard's app
- poll() samples every 250ms instead of 2000ms, keeping the caller's deadline
- authz.it.ts seeds its own invoice; it previously read another spec's leftover
and returned early, which silently passed on a pristine database
Known: an unlocked MAX(sequence_no)+1 in train-scheduling.service.ts races
under concurrent allocation and leaves a short consist, so 1-3 specs fail
intermittently. Pre-existing and reproduces at the production tick cadence.
- Updated OverviewContractsTabPanel to include a new donut chart for freight type distribution.
- Modified OverviewOperationsTabPanel to improve data visualization with additional charts and refactored data handling.
- Introduced CreateScheduleWindowFields component for configuring booking windows in train scheduling.
- Added new API endpoints for allocation candidates and booking allocation in trainScheduling.service.
- Enhanced BookingRequestsPage to support allocation of paid bookings with a modal for selecting alternative dates.
- Updated QUERY_KEYS and URLS constants to accommodate new operations and features.
- Improved type definitions for overview and train scheduling to support new functionalities.
Intercity bookings ride the wagons freed by earlier unloads (e.g. import
containers uncoupled at Dire Dawa). loadBooking now auto-allocates a
DOMESTIC booking onto on-train slots whose cargo has all departed —
greedy in consist order by capacity, container numbers copied for the
marshalling tally. Falls back to unallocated load when nothing is free.
- Implemented in the to manage the physical item capacity for each wagon type.
- Added a new migration to create the column in the table.
- Introduced method in to update rate units when cargo type unit of measure changes.
- Updated booking calculations to consider items per wagon for break-bulk cargo.
- Refactored various components to utilize the new items fit logic and ensure consistent date formatting across the application.
- Added tests for the new display timezone functionality to ensure consistent date/time representation across different user settings.
- Added pricing service integration to ContractsService for pre-persistence contract pricing.
- Updated LegCapacityPanel to display cargo weight instead of gross weight for better clarity on booked cargo.
- Enhanced train scheduling service to include cargo weight in booking details.
- Modified ClearanceDocumentsPage to include FULLY_EXECUTED status in booking status options.
- Refactored FileUploadSettingsPage to categorize file upload settings into tabs for better organization.
- Removed legacy onboarding fields and settings from file upload settings seeder.
- Improved type definitions for train scheduling to include cargo weight without wagon tare.
autoArriveAtFinalYard() bulk-updated booking status to ARRIVED/COMPLETED
via raw SQL but never emitted booking.unloadedAtYard, so
WarehouseInventoryService's listener never created the warehouse_inventory
row — bookings caught by this fallback (e.g. KALITY import arrivals)
stayed on awaiting unload indefinitely. Emit the event per row, covering
both intercity (DOMESTIC) and IMPORT as the listener already expects.
Update labels and comments to reflect that container returns are for
last-mile trucks only: either EDR last-mile or customer self-haul. Same
truck that delivered will return with empty containers. Changed labels
from "EDR Returns" → "EDR Last Mile" and "Customer Returns" →
"Customer Self-Haul".
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Separate page for tracking empty container returns by type: EDR returns
(empty containers from EDR first-mile) or Customer returns (customer
self-haul). Segmented control filter, expandable booking rows showing
containers, modal to record return with warehouse selection. Accessible
via sidebar menu under Import Operations.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Replace the fixed 5-minute grace with a settlement check at expiry:
expire() calls the payment API's reconcile endpoint — paid intents are
kept and allocated via payment.succeeded, unverifiable results defer
expiry to the next tick, only verifiably unpaid holds expire.
findByIdWithFullGraph loaded containerItems but not
containerItems.bookingContainer, so item.bookingContainer was always
undefined and the 40ft/20ft/total tallies on the Import/Export
Marshalling Document silently read as 0. Load containerType on both the
item and its bookingContainer, and resolve size from whichever is set.
Export and import marshalling documents now include:
- Company name column per cargo allocation row
- Executive summary with container counts (40ft, 20ft, total)
- Total weight already shown, now grouped with container data
Both export and import load list templates enhanced with same structure
for consistency. Container size calculated from booking container data.
- Introduced ContractCourtBadge to display the responsible party for contract actions.
- Updated ContractStatusBadge to include new court badge.
- Enhanced ClearanceDocumentsPage with additional filters for trade direction, freight type, and ownership.
- Modified ContractRequestDetailPage and ContractRequestsPage to utilize ContractCourtBadge.