We are experiencing an intermittent issue when reading Unity Catalog materialized views from downstream transformation notebooks.

Environment

• Azure Databricks
• Unity Catalog enabled
• Materialized views and streaming tables are created by a Lakeflow (formerly DLT) pipeline
• Source data is ingested from external storage as Parquet files
• Downstream transformation notebooks run as job tasks on Dedicated (Single User) Compute
• Jobs execute under the same service principal that owns the pipeline and materialized views
• All reads are performed using table/view names (spark.table(...) or SQL)
• No path-based reads are used anywhere in the application code
• Cluster policy uses auto:latest-lts, which currently provisions DBR 18.x runtimes

Issue

Since approximately October 2026, some jobs have started failing intermittently with the following error during the first read of a materialized view:

The reported path corresponds to the internal Unity Catalog managed storage location that backs the materialized view.

Observed Behavior

• Failure occurs on the first read of a materialized view.
• Reads of regular managed tables and streaming tables continue to work successfully.
• Only materialized-view reads are affected.
• Retrying the task on the same cluster consistently fails.
• Repairing/rerunning the job on a newly created cluster using the same runtime version succeeds.
• No code, permissions, storage configuration, or pipeline changes were made.

Historical Timeline

• Workloads have been running successfully for more than six months.
• Previously ran successfully on:
  • DBR 17.3 LTS
  • DBR 18.x releases observed prior to the issue
  • Serverless compute
• Failures began after clusters started showing a newer DBR 18.3.x maintenance release. Recently my job cluster used 18.3.9 release. 

What Has Been Ruled Out

• Concurrent pipeline updates
• Stale or dropped materialized views
• Ownership/permission issues
• External location overlap
• Code regressions
• Data changes

The pipeline was idle during several failures, and the same identities retain ownership and access to the affected objects.

Working Theory

The error appears to originate from Unity Catalog's managed-storage validation (CheckPathAccess) when resolving the underlying storage location of materialized views.

Given that:

• The same code succeeds on serverless compute.
• The same code succeeds on newly provisioned clusters.
• The same code worked for months before the recent runtime update (approx. running without any issues for 6 months)
• The failure specifically targets materialized views and not streaming tables or managed tables.

We suspect there may have been a change in how Dedicated Compute resolves materialized-view storage access, potentially involving:

• Table Credential resolution
• Managed storage path validation
• Unity Catalog authorization behavior
• Materialized-view materialization access paths

Questions

1. Has anyone observed similar LOCATION_OVERLAP or CheckPathAccess failures when reading Unity Catalog materialized views on recent DBR 18.x runtimes?

2. Were there any changes in how Dedicated Compute accesses materialized-view materializations compared with Serverless Compute?

3. Is there a known regression or behavioral change related to Unity Catalog managed-storage validation in recent DBR 18.x releases?

Any insights, known issues, release notes, KB articles, or recommended mitigations would be greatly appreciated