Flights search returns no results and Python API returns None

[isarko]

Version: flights 0.10.0
OS: Windows 11
Python: 3.13

Commands:

fli flights JFK LHR 2026-10-25 --format json
fli flights SJJ IST 2026-06-20 --format json
fli dates SJJ IST --from 2026-06-20 --to 2026-06-30 --duration 3 --round --format json

All return count=0.

Python API:

results = search.search(filters)

returns None.

airports command works correctly.

No network errors, no 403, no timeout.

[barronlroth]

Adding another repro from macOS, with the same failure shape plus a version sweep.

Environment:

• macOS 26.3 arm64
• pipx install path: /Users/barron/.local/bin/fli
• Package metadata: flights, repo/homepage https://github.com/punitarani/fli

Observed:

fli flights JFK LAX 2026-06-20 --format json

returns:

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

Same empty result on other obvious routes:

fli flights SFO LAX 2026-07-01 --format json
fli flights YLW SFO 2026-07-01 --stops 1 --sort DURATION --format json

But date buckets still work on at least some routes in 0.8.0:

fli dates YLW SFO --from 2026-07-01 --to 2026-07-01 --stops 1 --format json

returns:

{
  "count": 1,
  "dates": [
    {
      "departure_date": "2026-07-01",
      "return_date": null,
      "price": 247.0,
      "currency": "USD"
    }
  ]
}

Version sweep I tried:

• flights==0.8.0: dates works for the YLW/SFO bucket above; flights returns empty on JFK/LAX.
• flights==0.9.0: clean pipx reinstall flights initially fails with ModuleNotFoundError: No module named 'click'; after pipx inject flights click, flights is still empty, and the YLW/SFO dates check regressed to empty for me.
• git+https://github.com/punitarani/fli.git / flights==0.10.0: same missing click dependency on launch; after adding click, flights still returns empty on JFK/LAX.
• Older 0.6.0 / 0.7.0: no JSON output for flights; plain text still says No flights found for JFK/LAX.

So this looks broader than a single route or local install issue: flight-detail search is returning an apparently successful empty result even on trunk routes, while the date/price endpoint can still see inventory in some versions.

Related but separate: #197 / #198 cover the missing click runtime dependency in newer installs.

[alecsalisbury]

Tracked this down — it's not a per-route or install issue, and it's not (only) a parser break. The endpoint intermittently answers a valid request with HTTP 200 whose wrb.fr row carries no inner data payload but a typed gRPC error instead:

[["wrb.fr",null,null,null,null,[13,null,
  [["type.googleapis.com/travel.frontend.flights.ErrorResponse", ...]]]]]

13 is the canonical gRPC INTERNAL status. Because the HTTP status is still 200, the client's retry never fires, and the wire parser drops the unrecognised row (row[2] isn't a string) — so parse_first_wrb_payload returns None, search() returns None, and you get "No flights found" with no error. During a transient Google-side spell every request hits this, which is why it looked like a permanent, route-independent outage across all versions.

Easy to confirm: fire the same request repeatedly and it alternates between a full ~218 KB result and a ~360-byte ErrorResponse envelope.

Opened #201 with a fix: detect the envelope (wrb_error_code), raise a typed SearchBackendError that's retryable for transient codes (and fails fast on request errors like INVALID_ARGUMENT), and route the shopping/calendar/booking POSTs through a post_rpc helper that retries with backoff. Genuine empty results still return None. Tests included.

[barronlroth]

Follow-up / correction from my earlier repro: after retesting today in clean throwaway venvs, the failure is no longer reproducible for me on current PyPI latest when click is present.

Working clean tests now:

• flights==0.8.2: fli flights JFK LAX 2026-06-20 --format json returns 118 flights.
• flights==0.8.4: same, returns 118 flights.
• flights==0.9.0 + click: same, returns 118 flights.
• GitHub main / flights==0.10.0 + click: same, returns 118 flights.

I upgraded the actual pipx install to the released latest and repaired the missing dependency:

pipx uninstall flights
pipx install 'flights==0.9.0'
pipx inject flights click

Verification on macOS arm64 / Python 3.14.6:

fli flights JFK LAX 2026-06-20 --format json

returns:

{
  "success": true,
  "count": 118
}

And the original practical route now returns itinerary details too:

fli flights YLW SFO 2026-07-01 --stops 1 --sort DURATION --format json

returns count: 62, including Air Canada via YVR, United via YVR, and Alaska via SEA options.

So from my side this currently looks like either a transient Google/API/parser condition that cleared, or a version/cache/environment interaction. The separate missing dependency issue remains real: 0.9.0 and GitHub main still need click injected unless #198 or equivalent is merged/released.

[silvalucas9031]

The gate for the intermittent GetShoppingResults → HTTP 200 gRPC 13 INTERNAL is a valid x-goog-batchexecute-bgr (BotGuard) token — not IP reputation, not TLS fingerprint.

I ran controlled A/B tests, all through the same proxy IP, same minute, same f.req, only changing one variable at a time:

Client | Result (data vs gRPC 13) -- | -- Raw fetch (Node/undici), no bgr | ~1/6 data curl_cffi-style Chrome TLS (tls-client chrome_146), no bgr | ~1/6 data (tie with Node — TLS is not the gate) Headless Chromium (Playwright) | 0/3 data — worse than raw Headful Chromium (Playwright) | 6/6 data ✅ Headful, but with x-goog-batchexecute-bgr stripped via request interception | 1/4 data (collapses back to the raw baseline)

Conclusion: stripping only the bgr from the headful browser drops it from 6/6 → 1/4, and adding a valid bgr lifts a "dirty" datacenter/residential proxy from ~1/6 → ~100%. So the bgr is the gate.

The key nuance that explains the confusing earlier reports: the bgr must be valid.

• Valid bgr (real/headful browser) → ~100% success, even on a flagged IP, even in a "bad window".
• No bgr (raw fetch / curl_cffi) → ~baseline (~1/6) — you only get through during the gate's loose moments.
• Invalid/flagged bgr (headless browser — it does send a bgr, but BotGuard encodes the headless/automation signal into it) → ~0, i.e. worse than sending none.

What this rules out: IP reputation (headful succeeds on the same proxy that gives raw fetch 13), TLS/HTTP2 fingerprint (Chrome-TLS == Node here), and cookies (__Secure-ENID carried across requests made no difference).

Practical takeaway: a valid bgr can only be produced by a real (non-headless) browser running Google's BotGuard JS, and it's short-lived / bound to the page session (f.sid), so capturing-and-replaying it onto a fast HTTP client isn't reliable. The robust path is to let a headful browser (Playwright/Puppeteer, headless=false, e.g. via xvfb on a server) issue the request. curl_cffi impersonate="chrome" and bare-fetch clients work only opportunistically because they never carry a valid bgr.