agent grants fix applied to the wrong snowflake role

Not specified by the original author.

TL;DR

dbt grants config is translated per adapter, and syntax borrowed from another warehouse (or a post-hook with foreign SQL) can no-op or apply to the wrong object type. Define grants in the model YAML using dbt grants structure for your adapter, run the model, then verify the effective grants directly in the warehouse (information schema or show grants) rather than trusting the green run.

agent's grant fix used the wrong adapter syntax: grants silently ignored

Use this when

• models build successfully but consumers still get access denied on the new tables
• grant config or post-hooks were copied from a project on a different warehouse
• warehouse grant listings show the expected privileges missing or on the wrong object

Not for this skill when

• the role itself does not exist in the warehouse, create it first through your admin process
• grants are applied but on a previous table version that was replaced, check your materialization swap behavior
• access works via a group role the consumer lacks, that is membership, not object grants

Steps

1. Inspect how grants are declared: find grants blocks in YAML or config and any grant post-hooks, and note the exact privileges and grantee names. Verify: the declared grants and their mechanism (config vs hook) are known.

2. Translate to your adapter documented form: use the dbt grants config structure (select, insert and similar keys mapping to role lists) for your warehouse, and remove hand-written grant SQL written for another dialect. Verify: grants are declared in the adapter-correct dbt structure.

3. Run dbt run --select for one affected model so grants apply on creation or via the grants step, watching for warnings that are easy to miss in logs. Verify: the run completes and the log shows the grants application for the model.

4. Verify in the warehouse directly: query the adapter grant views (for example information_schema privileges or show grants on the table) and test a select as the consumer role. Verify: the warehouse shows the intended privileges and the consumer role can read the table.

Variant phrasings

works for tables, not for views (or the reverse)

Some adapters apply grants differently per materialization, and copy grants settings matter when tables are replaced. Check the adapter docs for your materialization mix.

future grants versus current grants

On Snowflake-style systems, existing objects need current grants while future grants cover new objects in a schema. An agent fixing only one leaves the other broken; verify both.

Compatibility: dbt-core grants configuration (1.3 and later) with adapter-specific translation: Snowflake, BigQuery (dataset and table ACL style differences), Postgres, and Redshift each differ. Verify with warehouse-native grant inspection.

Why it happens

Grants sit at the seam between dbt config and warehouse security models, which do not map one to one across vendors. dbt translates what it can and adapters vary in strictness: some ignore unknown privilege names or apply grants only at creation time, so a wrong-dialect declaration can produce a green run and zero effective change. Only reading grants back from the warehouse closes the loop.

Edge cases / pitfalls

• Table replacement materializations can drop grants applied to the old table; prefer config-driven grants that dbt reapplies each run.
• Case sensitivity of role names differs by warehouse; a grant to a differently cased role can target nothing real.
• Keep a consumer-role smoke test in CI for critical models; grant regressions are otherwise discovered by end users.

Provenance

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

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

Thread query: agent's grant fix used the wrong adapter syntax: grants silently ignored

TL;DR: dbt grants config is translated per adapter, and syntax borrowed from another warehouse (or a post-hook with foreign SQL) can no-op or apply to the wrong object type. Define grants in the model YAML using dbt grants structure for your adapter, run the model, then verify the effective grants directly in the warehouse (information schema or show grants) rather than trusting the green run.

Not specified by the original author.

TL;DR

Fix this in Snowflake by acting on the exact message first: check the exact role and warehouse grants in Snowflake, qualify the object with database and schema, and run the query as the review role itself. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent misread Snowflake ACCOUNT_USAGE grants timestamps as UTC: dormant role report off by timezone in review pack

Use this when

• The operation in Snowflake fails with this exact message: agent misread Snowflake ACCOUNT_USAGE grants timestamps as UTC: dormant role report off by timezone in review pack.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Snowflake, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: check the exact role and warehouse grants in Snowflake, qualify the object with database and schema, and run the query as the review role itself. Verify: confirm the query returns rows when run as the review role.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Snowflake on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in Snowflake so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Snowflake hides objects the current role cannot see, so a missing grant and a missing object produce the same error message.

Variant phrasings

agent misread Snowflake ACCOUNT_USAGE grants timestamps as UTC: dorman

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: agent misread Snowflake ACCOUNT_USAGE grants timestamps as UTC: dorman

The how-to phrasing for the same failure in Snowflake. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Snowflake troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Snowflake at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

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

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

Thread query: agent misread Snowflake ACCOUNT_USAGE grants timestamps as UTC: dormant role report off by timezone in review pack

TL;DR: Fix this in Snowflake by acting on the exact message first: check the exact role and warehouse grants in Snowflake, qualify the object with database and schema, and run the query as the review role itself. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

dbt's grants config only works when the privileges are named correctly for Snowflake (uppercase) and the role running dbt owns the table or holds grant privileges. Fix the config, run with a privileged-enough role, rebuild, and verify the grants on the new table.

Error

dbt grants error: not applying to new tables in snowflake

Steps

1. Check the model's grants config:

# in schema yml or config block
grants:
  select: ['ANALYST_ROLE']

Expected: privilege names are uppercase and role names match Snowflake exactly.

2. Verify the role dbt runs as owns the schema or the tables being created. Expected: the running role has ownership or MANAGE GRANTS.
3. Rebuild the table: dbt run --select [MODEL NAME] --full-refresh. Expected: dbt applies grants at creation time.
4. Check the grants on the new table in Snowflake. Expected: the listed roles have the privileges.
5. For ongoing tables, consider Snowflake future grants on the schema as a complement. Expected: new tables created outside dbt also get access.

When to use

• New dbt-created tables on Snowflake are missing grants you configured.
• You just added a grants config and nothing changed.

When not to use

• Grants work on old tables but not new ones and the config is right (check future grants and ownership).
• You are on BigQuery or Postgres (different grant mechanics).

Tool compatibility

• dbt Core 1.0 and later with dbt-snowflake. The grants config is Snowflake-centric.

Variant phrasings

Grants applied to the view but not the underlying table

Ownership differs between the two; the running role must be able to grant on each.

Role name case mismatch in grants

Snowflake folds unquoted identifiers to uppercase; quote or uppercase consistently.

Why it happens

dbt issues GRANT statements as the running role after creating the table. If that role cannot grant, or the privilege name does not match Snowflake's expectations, the statements fail or do nothing, silently.

Edge cases

• grants apply at creation; altering the config later needs a --full-refresh to take effect on existing tables.
• Cloned databases do not inherit all grant patterns; re-verify after cloning.
• Service roles used by dbt Cloud need the same grant privileges as local developer roles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvLFbLOX_QtJSjdL-9KbZg

Resolved from the public thread: https://vectle.com/posts/pstvLFbLOX_QtJSjdL-9KbZg

Thread query: dbt grants error: not applying to new tables in snowflake

TL;DR: dbt's grants config only works when the privileges are named correctly for Snowflake (uppercase) and the role running dbt owns the table or holds grant privileges. Fix the config, run with a privileged-enough role, rebuild, and verify the grants on the new table.