[igoramf]

Problem

bigquery_query page 2+ fails with 404 Not found: Job for any dataset outside the US/EU multi-regions (e.g. southamerica-east1).

Reproduced with a 3-row query and maxResults=1 against a southamerica-east1 dataset: page 1 works, and page 2 with the returned token 404s. bigquery_get_job on the same job also 404s without location and finds the job with it.

Cause: jobs.query (page 1) infers the region from the dataset, but jobs.getQueryResults (page 2+) looks the job up by id and needs location for non-US/EU jobs. The opaque pageToken stored only jobId + BQ token, which dropped jobReference.location, and getQueryResults never sent it.

Fix

• The pageToken now carries jobReference.location. Legacy two-part tokens still decode.
• getQueryResults sends location when it is known.
• The job-completion polling loops pass it too.

Tests

• New: location round-trips from page 1's token into page 2's URL. This test fails without the fix.
• New: a legacy token without location still decodes.
• bun test: 14 pass.

---

Summary by cubic

Fixes BigQuery queries 404ing with "Not found: Job" on page 2+ when the dataset is outside the US/EU multi-regions (e.g. southamerica-east1). The opaque page token now carries the job's location, and getQueryResults plus the job-completion polling loops send it when known. Legacy tokens without a location still decode.

Tests: new coverage verifies the location round-trips from page 1's token into page 2's request, and that legacy two-part tokens decode correctly.

^{Written for commit 4fc8062. Summary will update on new commits.}

[igoramf]

Verdict: LGTM: the location now goes from jobs.query into the token and back out to every getQueryResults call (round 1)

Blocking

None.

Worth fixing

None that should hold this PR.

Checked, fine

• Token format. The location is appended as a third field only when it is set. decodePageToken still accepts legacy two-part tokens. A job ID is limited to [A-Za-z0-9_-], and BigQuery location names have no newline in them, so splitting on \n is safe for both.
• Every caller passes location. Both polling loops (queryAndWait, queryOnePage) and the page-2+ path in tools/bigquery.ts send it. getJob / bigquery_get_job already took location as an input. No other caller of getQueryResults or encodePageToken exists in the package.
• US jobs. For these the location returned is US (or it is absent). Sending location=US is valid and matches the default.
• The new test. It asserts that location=southamerica-east1 appears in the page-2 URL. Without the fix the token drops the location, so that assertion fails. The legacy-token test covers backward compatibility.
• CI checks is green.