Common flight route broken: returns no flight

[deprov447]

Environment:

• fli installed via uvx
• Python 3.13 (also reproduced on 3.14)
• Route: BLR -> DEL
• Date: 2026-08-08
• currency=INR
• language=en-IN
• country=IN

CLI:

uvx --python 3.13 --from 'flights[mcp]' \
  fli flights BLR DEL 2026-08-08 \
  --class ECONOMY --stops ANY --sort CHEAPEST \
  --currency INR --language en-IN --country IN

Observed:
No flights found.

MCP search_flights returns:

{"success": true, "flights": [], "count": 0, "trip_type": "ONE_WAY"}

Expected:
BLR -> DEL has scheduled commercial flights on that date.

Also the log file:

timestamp: 2026-08-07T14:38:55.704395+00:00
command: flights
argv: ['/<>/.cache/uv/archive-v0/4U8qA9MZdSeo1pvV/bin/fli', 'flights', 'BLR', 'DEL', '2026-08-08', '--class', 'ECONOMY', '--stops', 'ANY', '--sort', 'CHEAPEST', '--currency', 'INR', '--language', 'en-IN', '--country', 'IN']
error_type: typer._click.exceptions.Exit
error_message: 1

traceback:
Traceback (most recent call last):
  File "/<>/.cache/uv/archive-v0/4U8qA9MZdSeo1pvV/lib/python3.14/site-packages/fli/cli/commands/flights.py", line 189, in _search_flights_core
    raise typer.Exit(1)
typer._click.exceptions.Exit: 1

[olivierbarbosa]

I hit the same symptom and traced it. Two things are going on, and only one of them is this library's fault.

The library-side defect — when Google declines a request it answers HTTP 200 with a payload-less wrb.fr row carrying an error code:

[["wrb.fr",null,null,null,null,[13]],["di",39],["af.httprm",38,"-196…",5]]

parse_first_wrb_payload returns None for that shape, _fetch_flights returns None, and the CLI prints No flights found — indistinguishable from a route with no service. #224 makes it raise with the code instead, so you'd see Google Flights returned error 13 (INTERNAL).

The underlying outage — GetShoppingResults now requires an X-Goog-BatchExecute-Bgr header generated by the page's JavaScript. Isolated it: replaying a request captured from the browser succeeds with that header and fails with error 13 without it, cookies removed either way. Not route-, date- or filter-specific — BLR → DEL on 2026-08-08 behaves the same as every other pair I tried. That part isn't fixable in a plain HTTP client, and #224 doesn't attempt it.

#224 also fixes a second, unrelated defect: the chunk framing desynchronises on any response containing non-ASCII text, which the checked-in ASCII-only fixture can't catch.

Investigated and debugged with Claude Opus 5, in collaboration.

[richardadonnell]

Independently reproduced, and I can confirm @olivierbarbosa's x-goog-batchexecute-bgr finding. Adding one further result that rules out the workaround most people will reach for first.

The header is the whole gate

I captured a real GetShoppingResults request from Chrome and replayed it with curl_cffi, varying one thing at a time:

Variant	Result
Full captured request (bgr header + f.sid/bl params)	155,694 bytes of payload
Identical, minus only x-goog-batchexecute-bgr	error 13
bgr kept, all URL params stripped	155,480 bytes of payload
fli's shape (bare URL, minimal headers, no bgr)	error 13

No cookies were sent in any variant. The header is necessary and sufficient, and f.sid / bl turn out to be irrelevant.

You cannot harvest a token and reuse it for your own queries

The obvious next idea is to grab a token from a browser and hand it to fli. That fails. Tested against a single freshly minted token, all four calls back to back in one run so expiry cannot explain the difference:

Body sent with that token	Result
The browser's own signed body	81,636 bytes of payload
fli's body, same route and date	error 13
The browser's body, one date digit changed	error 13
The browser's own signed body again	155,605 bytes of payload

The token is reusable, so it is neither single use nor short lived. It is bound to the exact request bytes, and changing one character voids it. So fli's query builder can never produce a body Google accepts, because only the page's own JavaScript can sign a given payload.

That seems worth stating plainly in the README or a pinned issue. This is not schema drift that a decoder update recovers from. #224 still deserves to merge for the error surfacing, since a silent count: 0 on a hard block reads as "this route has no flights" and costs people real debugging time. The search path itself is not recoverable in a plain HTTP client.

Environment: flights 0.9.0 from PyPI, Windows, Python 3.13.

Investigated with Claude Opus 5.