agent schema change dropped a column dashboards still query

Not specified by the original author.

TL;DR

The agent dropped a column something still reads. Restore the column (revert the model or re-add it as a deprecated alias), fix the dashboards or downstream models to stop using it on a schedule, and only then drop it for real. Column removal is a migration, not a one-line edit.

Error

agent schema change dropped a column dashboards still query

Steps

1. Confirm the breakage: check dashboard errors or dbt compile failures naming the missing column, and git diff the agent's change to see the drop. Expected: You see the dropped column and every downstream reference to it.

2. Restore the column immediately: revert the model's select to include it again (even as a deprecated pass-through) and rebuild. Expected: Dashboards and downstream models work again.

3. Inventory all consumers of the column: grep the dbt project, check BI tool definitions, and ask owners. Migrate each consumer to the replacement. Expected: A consumer list with migration status per consumer.

4. Once no consumer references it, drop the column with a changelog note. Add a policy: agents may not drop columns without a consumer check. Expected: Clean removal, no breakage, policy in place.

When to use

• an agent dropped a column that dashboards or models still query
• dashboard errors naming a missing column after an agent edit
• dbt compile fails on a column that existed yesterday

When not to use

• the column drop was planned with all consumers migrated (that is a proper deprecation)
• the column never existed (that is a different bug)
• nothing references the column (then the drop is fine, carry on)

Tool compatibility

• git diff to see the agent's schema change
• dbt compile to find downstream references
• BI tool field usage to inventory dashboard consumers

Variant phrasings

agent renamed the column instead of dropping

Same breakage, different shape. Restore the old name as an alias, migrate consumers, then remove the alias.

agent dropped the column from a seed

Seeds feed models directly; restore the CSV column and rebuild the seed with --full-refresh.

Why it happens

Agents see an unused-looking column in one model and remove it, not knowing the BI layer or a downstream mart reads it. dbt's ref graph does not include dashboards, so the agent's blast-radius check misses them entirely.

Edge cases

• Exposures in dbt can track dashboard dependencies; define them so the next agent sees the consumers.
• A deprecated column should carry a comment with the removal date, or the migration never finishes.

Provenance

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

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

Thread query: agent schema change dropped a column dashboards still query

TL;DR: The agent dropped a column something still reads. Restore the column (revert the model or re-add it as a deprecated alias), fix the dashboards or downstream models to stop using it on a schedule, and only then drop it for real. Column removal is a migration, not a one-line edit.

Not specified by the original author.

TL;DR

Refresh the cached table schema instead of rewriting the query: Trino caches remote table metadata, so a column dropped at the source keeps failing until the cache is invalidated or the table is re-registered in the connector. The stale schema error means Trino planned the query against a column list that no longer matches the remote table. The query text is fine; the catalog copy of the schema is old.

trino query failed error "schema is stale: column dropped in remote table"

Use this when

• The check or run fails with this symptom: a Trino query fails with schema is stale and a column dropped in the remote table.
• You are working on a Trino catalog over a remote or federated table whose schema changed at the source and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A column that was renamed rather than dropped, where queries need the new name and a cache refresh alone is not enough.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Confirm the current remote table schema directly in the source system. Verify: the dropped column is really gone at the source
2. Find queries and views that still reference the dropped column. Verify: every dependent reference is listed before the refresh
3. Invalidate the connector metadata cache for the table, or drop and recreate the table registration where the connector requires it. Verify: Trino describes the table with the new column list
4. Update the dependent queries and views to the current schema. Verify: they plan successfully
5. Rerun the original query. Verify: it completes against the refreshed schema

Variant phrasings

trino schema is stale column dropped remote table

The shorter phrasing focused on the named failure.

trino query failed schema stale error

The symptom phrasing a searcher tries next.

trino stale schema cache refresh fix

The variant naming the failing stage or tool directly.

Compatibility: Trino 4xx releases, JDBC and metastore backed connectors with metadata caching

Why it happens

Federated connectors cache table metadata to avoid a remote lookup per query. When the source drops a column, the cache and the real schema diverge, and Trino raises the stale schema error rather than planning against a table shape that no longer exists.

Edge cases / pitfalls

• A view defined over the table keeps the old column list even after the cache refresh; views must be replaced explicitly.
• Short cache lifetimes hide this in development and expose it in production; align the cache settings across environments.

Provenance

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

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

Thread query: trino query failed error "schema is stale: column dropped in remote table"

TL;DR: Refresh the cached table schema instead of rewriting the query: Trino caches remote table metadata, so a column dropped at the source keeps failing until the cache is invalidated or the table is re-registered in the connector. The stale schema error means Trino planned the query against a column list that no longer matches the remote table. The query text is fine; the catalog copy of the schema is old.

Not specified by the original author.

TL;DR

Sync the database schema in Metabase first, then open the failing question and replace the removed or renamed field everywhere it appears, including filters, groupings and sorts. Save the question, clear the card cache, and reload the dashboard so every copy of the card uses the fixed question. Renaming upstream without updating saved questions is the usual trigger.

column does not exist

Use this when

• One card fails with a column error while other cards on the same database still work.
• A warehouse migration renamed or dropped a column used by saved questions.
• The notebook editor shows a field highlighted as unavailable in the failing question.

Not for this skill when

• Every card on the database fails at once. Check the database connection before editing questions.
• The card loads but shows wrong values with no error. That is a definition problem, not a missing column.

Steps

1. Open the failing question directly, not from the dashboard, and run it to see the full database error naming the column. Verify: the error names a single column that no longer exists in the table
2. In Admin settings for the database, run a manual schema sync and then inspect the table field list in the data model. Verify: the new or renamed column appears and the old name is gone
3. Edit the question and replace the old field in the data step, filters, summaries, breakouts and sorts with the current field. Verify: the question runs and returns rows in the editor
4. If the question is native SQL, update the column name in the query text and check any field filter mappings that point at the old field. Verify: the query runs with the dashboard filters applied
5. Save the question, clear cached results for the card from the admin caching page, and reload the dashboard as a viewer. Verify: the card renders current data with no error banner
6. Search saved questions and models for other uses of the old column name and fix them before they are opened. Verify: a search for the old name in question definitions returns no active items

Why it happens

Metabase separates the synced field catalog from the queries stored in saved questions. Schema changes propagate to the catalog on sync, but stored questions keep the identifiers they were saved with, so the database rejects them at run time. Models add a second copy of the field reference, which is why fixing the dashboard card alone sometimes leaves the underlying model broken. Updating every stored reference is the durable fix.

Metabase saved questions store field references against the synced field list. When a column is dropped or renamed in the warehouse, the generated query still asks for the old name and the database returns a column error that Metabase shows on the card. A schema sync alone does not rewrite saved questions, it only makes the new field available to pick. Cards built on a model or a cached result can keep failing until the question itself is corrected.

Field notes for Metabase specifically. The admin troubleshooting area, the task history, and the application database query tools give the evidence for most incidents, and the audit views on paid plans show who changed a question or a dashboard and when. Metabase behaviour differs meaningfully between the open source and paid builds, and between the application database choices underneath, so note the exact version when filing or searching for an issue. A question that works in the editor but fails on a dashboard is almost always a dashboard layer setting, which is why the two surfaces should always be tested separately.

For Metabase teams, models are the control point worth investing in. Questions built directly on raw tables inherit every schema change at full force, while models give the team one place to absorb a rename or a type change before it reaches fifty saved questions. Keeping production dashboards on models, and raw table questions in a clearly marked sandbox collection, measurably reduces breakage after warehouse changes. It also gives the schema sync somewhere forgiving to land, since the model owner sees the change before viewers do.

Variants and edge cases

Metabase column does not exist after rename

The rename-triggered phrasing for saved questions.

Metabase saved question broken column sync schema

The sync-focused variant for recently migrated tables.

Metabase dashboard card error missing field fix

The dashboard-level phrasing viewers report.

Provenance

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

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

Thread query: Metabase dashboard card failed with error "column does not exist" how to fix

TL;DR: Sync the database schema in Metabase first, then open the failing question and replace the removed or renamed field everywhere it appears, including filters, groupings and sorts. Save the question, clear the card cache, and reload the dashboard so every copy of the card uses the fixed question. Renaming upstream without updating saved questions is the usual trigger.