bigquery table must be qualified with a dataset

Not specified by the original author.

TL;DR

Point the source at the dataset and table that exist, in the location they actually live in, by setting the BigQuery dataset location in the offline store config to match (for example a regional dataset instead of US), because BigQuery refuses a table lookup when the query location and the dataset location differ. Start with the Feast BigQuery source config and the dataset location in the BigQuery console, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchanged.

Feast BigQuery offline store failed error "NotFound: table was not found in location US"

Use this when

• You see this exact message or symptom: Feast BigQuery offline store failed error "NotFound: table was not found in location US"
• One run, record, call, or object is affected and you can name it
• A retry without changing anything reproduces the same result

Not for this skill when

• The system fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once using the Feast BigQuery source config and the dataset location in the BigQuery console, and record the time, the workspace or account, and the one item it names. Verify: you have one failing item identified, not a similar older failure
2. Inspect the fully qualified table name in the data source, the dataset location shown in BigQuery, and the location value in the offline store config. Verify: you can point to the specific value, field, segment, or state that does not match what this operation needs
3. Apply the fix at that source: Point the source at the dataset and table that exist, in the location they actually live in, by setting the BigQuery dataset location in the offline store config to match (for example a regional dataset instead of US), because BigQuery refuses a table lookup when the query location and the dataset location differ. Verify: the corrected value or setting is visible in the system itself, not only in a local file or the agent notes
4. Re-run the original operation on the single affected item first. Verify: that one item completes with no trace of the failure described above, and the online and offline values for that entity agree
5. Check the downstream result a user or the next job would see, comparing it against the source for the same item. Verify: the downstream result agrees with the source in content and in timing
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the failure and the fix, and no earlier item regressed

Variant phrasings

Feast BigQuery offline store failed error "NotFound: table was not found in location US"

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the item the log or record names.

Tool-first phrasing of this failure

The phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does this keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the input, setting, or record state, not in the attempt.

Compatibility: Feast 0.36 or later, BigQuery offline store, datasets in US, EU, or single regions.

Why it happens

Datasets created outside the console often land in a region while Feast defaults to the US multi-region. BigQuery treats a location mismatch as not found rather than as a location error, which sends people hunting for a deleted table that still exists.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstDDkuExmqgVfN3sqkjBjpg

Resolved from the public thread: https://vectle.com/posts/pstDDkuExmqgVfN3sqkjBjpg

Thread query: Feast BigQuery offline store failed error "NotFound: table was not found in location US"

TL;DR: Point the source at the dataset and table that exist, in the location they actually live in, by setting the BigQuery dataset location in the offline store config to match (for example a regional dataset instead of US), because BigQuery refuses a table lookup when the query location and the dataset location differ. Start with the Feast BigQuery source config and the dataset location in the BigQuery console, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than r

Not specified by the original author.

TL;DR

The table and the query are probably in different places, literally. BigQuery datasets live in one location, and a job that looks in US cannot see a table whose dataset sits in another location such as the EU, while a fully qualified name alone does not move the job. Check the datasets real location, run the job in that location or move the pipeline coherently, and the not found error clears without recreating anything.

BigQuery Not found Table usage_daily was not found in location US: health score pipeline broken

Use this when

• The pipeline fails with Not found Table and names a location such as US
• The table is visible and queryable in the BigQuery console under some project
• A migration, new dataset, or new orchestration region was introduced recently

Not for this skill when

• The tables expiration passed and it was deleted, which the dataset listing and table details will show
• The failure is a permission error dressed differently, which appears as an access denied message instead

Steps

1. Open the dataset containing usage_daily in the BigQuery console and read its location from the dataset details, then read the project and dataset the pipeline actually references from its configuration. Write both down exactly, because project, dataset, and location mismatches often hide behind similar names across environments such as production and staging copies. Verify: dataset location and the pipelines referenced project and dataset are recorded side by side
2. Check the location your job runs in. In the job history or your orchestrators configuration, find the location the query job was submitted with. Console queries inherit the datasets location, which is why the same SQL succeeds by hand, while scheduled jobs often default to US or to the orchestrators own region setting regardless of the dataset. Verify: the submitted job location is identified from job history or configuration
3. Align location end to end. Either submit the job in the datasets location, or, if the architecture intends US, recreate the table in a US dataset through the upstream pipeline, never by a one-off manual copy that the next pipeline run will overwrite or ignore. If the query joins datasets in two locations, that join can never work, and the real fix is co-locating the datasets through the pipeline design. Verify: the job and all joined datasets share one location, confirmed in configuration
4. Fully qualify the table name with project and dataset in the pipeline SQL and pin the location in the job configuration or connection settings, so a future environment default cannot silently repoint the run. Keep environment specific values in configuration, not pasted into SQL strings scattered across the pipeline. Verify: the corrected pipeline run completes and reads the expected row count for usage_daily
5. Recover the missed health scoring. Re-run the pipeline for every failed date, reconcile daily usage counts against the source systems totals, and re-score accounts whose health inputs were missing, annotating the dashboards so the stale period is not mistaken for a usage collapse. Verify: missed dates are reprocessed and reconciled with scoring refreshed
6. Document the location decision in the dataset description and the pipeline runbook, including which datasets must stay co-located for joins, and add a pipeline assertion that fails early if the configured location differs from the datasets actual location, turning the next migration mistake into a loud configuration error instead of missing tables. Verify: the assertion exists and fails in a test run with a deliberately wrong location

Why it happens

BigQuery is location strict. A query job runs in one location and can only touch datasets stored there, and it reports tables elsewhere as not found in the jobs location. Interactive console use masks this because the console picks the datasets location for you. Scheduled pipelines carry their own location default, so a dataset migration or a new region setting breaks them while every manual check passes.

Compatibility: BigQuery datasets and job locations, job history, and orchestration tools such as Airflow or dbt with BigQuery connections, in current versions.

Variants and edge cases

BigQuery not found table was not found in location US

['The verbatim phrasing. The location named in the error is where BigQuery looked, not where the table is, and that distinction is the whole diagnosis.']

BigQuery table exists but job says not found

['The console-versus-job phrasing. Trust the dataset details page for location and the job history for the submitted location, and compare those two facts first.']

BigQuery dataset location mismatch pipeline

['The migration variant, common when a EU dataset was created by a privacy or residency project while orchestration kept a US default. Co-location decisions need the data owner, not only the engineer.']

Edge cases to work through before you close the incident:

• Table names in errors can include a generated project or dataset from a template variable. Log the rendered SQL and configuration at runtime, not the template, when you diagnose.
• Wildcard tables spanning datasets still obey location rules. A wildcard does not rescue a cross-location design.
• Copying a table across locations is possible with transfer or export jobs, but a copied table goes stale instantly. Fix the pipeline location or the dataset location, not the symptom.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FDWwXYUvp9HwBugnAGsSJg

Resolved from the public thread: https://vectle.com/posts/pst_FDWwXYUvp9HwBugnAGsSJg

Thread query: BigQuery Not found Table usage_daily was not found in location US: health score pipeline broken

TL;DR: The table and the query are probably in different places, literally. BigQuery datasets live in one location, and a job that looks in US cannot see a table whose dataset sits in another location such as the EU, while a fully qualified name alone does not move the job. Check the datasets real location, run the job in that location or move the pipeline coherently, and the not found error clears without recreating anything.

Not specified by the original author.

TL;DR

The query references project.dataset.table and BigQuery cannot see it. Usually the table has not been built yet in this target, or the dataset or project in your profile is wrong. Check the fully qualified name in the compiled SQL, verify the dataset exists, and build the missing upstream model first.

Error

BigQuery Not found: Table error in dbt run

Steps

1. Open target/compiled for the failing model and copy the fully qualified table name from the error. Expected: You have project.dataset.table exactly as BigQuery saw it.

2. In the BigQuery console, check the dataset exists in that project and region. Dataset region must match the job region. Expected: You confirm the dataset exists, or you find the project or region is wrong.

3. Check whether the table is a dbt model that has not been built in this target yet: run dbt ls --select +the_model to see its upstream chain. Expected: You find the unbuilt upstream model.

4. Build upstream first: dbt build --select +thefailingmodel, or fix the profile's dataset/project if those were wrong. Expected: Upstream tables exist, the failing model builds clean.

When to use

• BigQuery Not found: Table during dbt run
• a model refs another model that was never built in this target
• profile points at the wrong project or dataset

When not to use

• access denied on the table (that is IAM, not not-found)
• dataset location mismatch errors (region error, different message)
• the table exists but the query is wrong (that is SQL logic)

Tool compatibility

• dbt-bigquery adapter; profile dataset and project settings
• BigQuery console to verify datasets and regions
• dbt build --select +model builds upstream chain first

Variant phrasings

Not found: Table on a source

The source table itself is missing or the source definition's dataset is wrong. Check sources.yml against the real dataset.

Not found only in a new target

The target uses a different dataset that was never populated. Build the full DAG into it once, or point the target at the shared dataset.

Why it happens

BigQuery resolves the full three-part name at query time. dbt generates that name from your profile (project, dataset) plus the model config. Any mismatch, or any upstream model not yet materialized in that dataset, reads as not found.

Edge cases

• BigQuery dataset regions matter: a dataset in EU queried from a US job fails differently, but a wrong-region dataset name can also surface as not found.
• Table expiration can delete tables out from under you; check the dataset's default table expiration if tables vanish.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstyxSEVSwOKRVExTVypxVfA

Resolved from the public thread: https://vectle.com/posts/pstyxSEVSwOKRVExTVypxVfA

Thread query: BigQuery Not found: Table error in dbt run

TL;DR: The query references project.dataset.table and BigQuery cannot see it. Usually the table has not been built yet in this target, or the dataset or project in your profile is wrong. Check the fully qualified name in the compiled SQL, verify the dataset exists, and build the missing upstream model first.