inconsistent behavior with serverless sql: user is not an owner of table error with views

[ceceliac]

We get the following error with some basic views and not others when using serverless compute (from a notebook or from SQL Editor or from the Catalog Explorer).  Views are simple select * from table x and underlying schemas/tables are using managed metastore for storage.  Views work fine if we switch to classic compute.  I've opened a suppoort ticket but not getting resolution there yet so if anyone has ideas, it would be appreciated.  Thanks!   

Your request failed with status FAILED: [BAD_REQUEST] PERMISSION_DENIED: User is not an owner of Table

[VZLA]

Hi @ceceliac , thanks for your question!

I believe the issue you're referring to is limited to the "serverless SQL warehouse." Other SQL warehouses or serverless clusters should be fine. Databricks' Support team is isolating its root cause before a fix can be provided. Could you please touch base on the support ticket? Kind regards.

[ceceliac]

Hi Vzla, here is the ticket number: CASE NUMBER # 00578817

[Walter_C]

When you use the classic compute do you set it as single user cluster or shared cluster? If single user cluster can you change it to be shared, this is because serverless acts as a shared cluster due to this wanted to see if both clusters are in same conditions.

[ceceliac]

Hi,

Thanks for the responses!  If I use shared classic compute, the queries work fine (from a notebook or viewing sample data in the catalog explorer).  If I use serverless from a notebook, single-user classic compute, a SQL warehouse of any type (serverless, pro or classic), I get the error.  The issue is specific to views.  The only difference I can see is with the properties of the underlying tables: 

views that are working reference tables that have these properties:

delta.lastCommitTimestamp=1731062236000
delta.lastUpdateVersion=0
delta.minWriterVersion=7
delta.enableDeletionVectors=true
delta.minReaderVersion=3
delta.feature.deletionVectors=supported
delta.feature.invariants=supported

views that are NOT working reference tables that have additional properties:

delta.lastCommitTimestamp=1733497202000
delta.lastUpdateVersion=29
delta.minWriterVersion=7
delta.feature.generatedColumns=supported
delta.feature.appendOnly=supported
delta.enableDeletionVectors=true
delta.minReaderVersion=3
delta.feature.changeDataFeed=supported
delta.feature.checkConstraints=supported
delta.columnMapping.mode=name
delta.feature.deletionVectors=supported
delta.columnMapping.maxColumnId=14
delta.feature.columnMapping=supported
delta.feature.invariants=supported

[VZLA]

Thanks for the details, could you please share these in the Support Ticket? I've reached out to the engineer and shared some internal information that could help with the problem.

[ceceliac]

Hi, I updated the ticket with the details above.  I don't think it's the table properties after all.  We found at least one example where the properties matched and 1 view worked while the other did not.  I modified the script that was used to create the views and replaced the "create view if not exists" with "create or replace" and we recreated the views.  This seemed to resolve the issue but we don't know the root cause.  Thanks! 

[VZLA]

@ceceliac just a quick check, if you rerun the same query after it has initially failed, will it go through or still fail? if it runs fine, wait another 10-15mins and rerun it and share the outcome. So:

1.- Run it once, it will fail.

2.- Rerun it inmediatly after, does it fail or succeed?

3.- If it suceeds, after waiting for some time, will it fail or succeed?

This will help with internal research.

[ceceliac]

Hi, FYI - it looks like this is a bug and the fix is due Q1.  Perhaps you're already aware of that. It seems at least a few others have reported the issue by now. If you query the view as the owner after an underlying table is modified, the view gets recompiled and there is no error when querying it with serverless.