Hotels the Platform Delisted Stop Being Priced
The row is still on the list; the hotel it points to is gone.
Some rows in a tenant’s catalogue are linked to platform hotels. When that platform hotel is deleted, the row is treated as not distributable, with the reason delisted by the platform: price monitoring runs exclude it, and rate requests stop it before a dead hotel ID reaches a supplier.
What happens when a catalogue row points at a hotel the platform has deleted? The row looks normal. It is still treated as on sale, it joins the price-monitoring targets, and rate requests still go out to the supplier, whose only possible answer is that the hotel does not exist. That row can never return a price.
The eligibility check did not cover this case. When deciding whether a catalogue row could be distributed, the system only verified the platform side if the row carried a valid platform hotel ID. Once the platform hotel was deleted, that ID read back as empty, so the check was skipped and the target went through.
A catalogue row linked to a platform hotel that no longer exists is not distributable, with the reason recorded as delisted by the platform, which makes clear it is the platform’s state rather than a fault in the tenant’s catalogue. Monitoring runs exclude it during preparation, and the distributability check on rate requests blocks it. The fix sits in that check. The supplier ID resolver is unchanged, because falling back to platform mapping when a catalogue record is missing is normal behaviour that partially filled catalogues rely on.
Catalogue rows that use only the tenant’s own hotel IDs and were never linked to a platform hotel are unaffected; they never depended on the platform side, and the rule for them is unchanged. The platform records how many targets were excluded and why while a run is being prepared, so a dead target is caught before any supplier is asked.