From non-stop only to one-stop fallback: relaxing the filter
Why setting `non_stop: true` on PHL→DXB used to silence good fares — and what the scraper does now.
Non-stop preference is the right default for short-haul. PHL→ATL has 12 daily nonstops on AA alone — there's never a reason to take a connection. Long-haul is different. PHL→DXB has zero non-stops most days; the only Emirates option is via JFK or BOS. A target with `non_stop: true` on a route like that produced a constant stream of 'no flights returned' errors and never alerted, even when the 1-stop fare crashed.
The fallback
When the scraper has `non_stop: true` and the SerpAPI response comes back empty (search_metadata.status is fine, just no inventory), we now retry once with `stops=2` (which SerpAPI interprets as 'up to 1 stop'). If THAT returns inventory, we run the same tier-1 carrier filter, take the cheapest, and tag the raw summary with `[1-stop fallback]` so you can see what served the result.
What it does NOT do
The fallback only triggers on the literal 'no flights returned' error. If the response had inventory but everything was Spirit / Frontier / unknown carriers, the error becomes 'no tier-1 flights' and the fallback does NOT fire — there's nothing to retry, the carriers were the problem, not the routing. Same for HTTP 4xx/5xx: those propagate cleanly so the auto-pause counter advances when something is genuinely broken.
Together with flex-dates
When `flex_days` is set on a non-stop target, each date in the window independently tries the fallback. So a `flex_days: 1, non_stop: true` target on PHL→DXB will issue up to 6 SerpAPI calls (3 dates × {non-stop attempt + 1-stop fallback}) — but only when each date's primary attempt actually returned no flights. Most dates resolve in the first call.