fix(google-big-query): pass the job location when fetching result pages

IG
11d ago
+132-7

Why

bigquery_query pages through jobs.getQueryResults but never sends location. BigQuery requires it for jobs outside the US/EU multi-regions and otherwise answers 404 "Not found: Job". Page 1 works because jobs.query returns it inline, but every page after that fails for datasets in a single region.

Production case: plp-optimizer's funnel extraction for Monte Carlo (montecarlo-analytics.analytics_305041776, southamerica-east1). Once a 3-day chunk's response stopped fitting in one page, the chunk failed with:

BigQuery API error: 404 - https://bigquery.googleapis.com/bigquery/v2/projects/montecarlo-analytics/queries/job_...?maxResults=50000&pageToken=...

The extraction deletes a day before rewriting it, so this left holes in the tenant's funnel store. They were recovered by re-running one day at a time.

What

  • queryOnePage returns jobReference.location.
  • The tool encodes it into the opaque nextPageToken (jobId\napiToken\nlocation) and passes it to getQueryResults on the next call.
  • getQueryResults accepts location, and both polling loops (queryAndWait, queryOnePage) pass it too.
  • Tokens issued before this change (two parts) still decode, so pagination already in flight doesn't break on deploy.

Tests

bun test in google-big-query: 15 pass. The new tests cover:

  • the first page's token carries the location;
  • page 2 sends location=southamerica-east1 and keeps it in the token for page 3;
  • legacy two-part tokens still decode.

Root check passes for google-big-query. The mcp-studio type errors also occur on main and are unrelated.

Summary by cubic

Fixes bigquery_query pagination returning 404 "Not found: Job" for jobs outside the US/EU multi-regions (e.g. southamerica-east1). jobs.getQueryResults requires location, but the tool never sent it; page 1 worked because jobs.query returns it inline, so every page after that failed once a result set spanned multiple pages.

Bug Fixes

  • queryOnePage now returns the job's location, which is embedded in the opaque token and passed to getQueryResults on page fetches and in both polling loops.
  • Tokens issued before this change (only jobId + apiToken) still decode, so pagination already in flight keeps working at deploy.