When Time Runs Out, Keep the Quotes That Already Arrived
The supplier already answered; being half a step late on our side should not erase that.
Streaming hotel search runs on a time budget. A batch a supplier had already returned, but that was still being mapped and priced when the budget ran out, used to be dropped and logged as a supplier timeout. Such batches now get up to two seconds to finish, while a user’s own cancellation still drops them at once.
In a streaming search, a supplier returned a full batch of quotes inside the budget. After the response come hotel mapping and pricing rules, and only then can results be pushed to the page. Mapping and pricing rules occasionally take a little longer than the budget allows; when the budget ran out, the whole batch was dropped and logged as a supplier timeout.
Cancellation means several different things. A user closing the page truly no longer wants the results. A seller-level failure that requires giving up on the whole scope should stop things at once. The budget running out only means stop waiting for new replies; it never meant discard what already arrived. The old code treated all of these the same way.
Once a supplier response has succeeded, mapping, pricing rules and delivery move onto their own deadline: up to two seconds after the budget runs out. Only an expired budget gets this extra time. User cancellation and failures that must give up are still dropped immediately, and a response cancelled by the user still never enters mapping or rules. When no such batch is in progress, the search still closes after the usual 100-millisecond grace, so nothing gets slower.
This change leaves the budget itself alone. The budget decides whether to keep waiting for new replies; the finishing window looks after batches that already have their reply and need only mapping and pricing rules to finish. A search with no such batch in hand finishes exactly when it did before, and searches without a time budget are not affected at all.