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.

[Princeu3]

Opened #230, which restores search rather than only reporting the block.

The header gate holds exactly as @olivierbarbosa and @richardadonnell described — I could not get GetShoppingResults to answer without a browser-signed x-goog-batchexecute-bgr, and a token bound to one body is useless against another. But the RPC is not the only way to the data. The public /travel/flights page is not gated, and it embeds the same payload inline in an AF_initDataCallback blob keyed ds:1: ds:1[2] and ds:1[3] hold exactly the flight rows the RPC returned, so _decoders reads them unchanged.

The page is addressed by the tfs protobuf instead of f.req. build_tfs_token already encodes tfs for booking deep links, so #230 shares that field layout rather than adding a second encoder.

Live JFK → LAX now returns 32 one-way options at $204 and 38 round-trip itineraries at $357, cross-checked against an independent Google Flights source. Date search has no page-side calendar, so it prices each date with its own fetch — an eight-day sweep takes about 1.5 seconds.

Alliance, emissions, bag and basic-economy filters have no page equivalent and are logged as ignored; airline, price, duration and time-window filters are applied to the decoded results instead.

get_booking_options still rides GetBookingResults and is presumably gated the same way. #230 leaves it raising a named error rather than returning empty.