Half an Answer Is Never Remembered as the Whole
People sharing a ride should not all get out halfway because the first passenger was in a hurry.
When several requests ask the same supplier for the same data at once, the system merges them into one query. Each caller now waits on its own clock and the shared query is cancelled only when the last one leaves; results cut short by time come back with their error and are never cached as a complete answer.
On busy dates, several buyers often ask the same supplier about the same hotels at almost the same moment. Rather than ask the same question several times, the system merges those requests into one query and everyone shares the answer. It saves cost and the call quota suppliers allow, but it brings two problems that are easy to miss.
First, every request has its own time budget. If the merged query follows the first caller’s deadline, later callers with time to spare are stopped along with it. Second, a batch of hotels is often asked in several smaller pieces. When time runs out, some pieces are back and some are not. That result is incomplete, and if it is cached as a complete answer, the next identical request gets the partial result straight from the cache without the supplier being asked again.
Each caller on a merged query is tracked on its own: it waits only as long as its own time allows and leaves when that runs out, and the shared query is cancelled only after the last caller has gone. A batch cut short by time hands back the valid results it has together with the original timeout error; seeing that error, the search does not cache those results as a complete answer or count them as a success. The caching rules themselves are unchanged.
On a normal day, buyers will not see any of this. What they get is the other side of it: a result cut short once is never served later as the full answer to the same question, and merging queries does not cut anyone off early. We did not add any extra time to anyone’s budget for this.