Accommodation Live Cutover Observations
Route checks performed
Checked through the live API gateway on http://localhost:4001 after the env flip:
GET /api/v1/accommodations?page=1&pageSize=1GET /api/v1/accommodations/ACC-GE-2026-0102POST /api/v1/accommodations/ACC-GE-2026-0102/quoteGET /api/v1/my-accommodation-bookingsGET /api/v1/owner/accommodation-listingsGET /api/v1/owner/accommodation-reservationsPOST /api/v1/accommodation-listingswithout bearer token
Auth observations
- authenticated owner and booking-read routes behaved the same as before
- missing-token mutation denial remained
401 missing_bearer_token - no auth-specific regression was observed in the checked set
Response / status observations
- public list matched extracted runtime response
- public detail matched extracted runtime response
- owner listing and owner reservation reads matched extracted runtime response
my-accommodation-bookingsmatched extracted runtime response- denial-path status and body matched extracted runtime response
Quote / read observations
- quote response remained correct and matched the extracted runtime modulo request-time
computedAt - public accommodation read paths remained correct after cutover
- owner and booking read paths remained correct after cutover
Any anomalies
No blocking anomaly was observed.
Accepted request-time variance:
- quote
computedAttimestamp differed by a few milliseconds between separate requests
This is not treated as backend drift.
Compatibility residue note
Compatibility residue still exists even though it did not surface in the checked cutover set:
services/svc-tenders/src/accommodation/compatibilityReadRepository.ts- root accommodation compatibility hosting in
services/svc-tenders/src/repository.ts
The live cutover window does not mean those old-host-only compatibility surfaces are gone.
Rollback note
Rollback was not used.
Old accommodation hosting remained available during the window, so the rollback path stayed:
- revert
ACCOMMODATIONS_SERVICE_URLtohttp://localhost:4020 - restart
services/api