[Bug] Cross-workspace view models fail with "Artifact not found" error

[cheyney-w]

Is this a new bug?

• I believe this is a new bug
• I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

I mentioned this issue in #165 (here) but thought I'd raise a new issue for visibility's sake.

Attempting to materialize a view model in another workspace using the new cross-workspace feature results in an error.

For example, if the project is configured to connect to a lakehouse in a workspace called MainWorkspace and you configure a model to materialize as a view in a lakehouse called OtherLakehouse in a workspace called OtherWorkspace, you get an error.

This model fails:

{{ config(materialized='view', database="OtherLakehouse", workspace_name="OtherWorkspace") }}

select explode(sequence(1,5)) as id

with an error like this:

12:16:26  1 of 1 START sql view model OtherWorkspace.OtherLakehouse.dbt.test_model ...... [RUN]
12:16:33  1 of 1 ERROR creating sql view model OtherWorkspace.OtherLakehouse.dbt.test_model  [ERROR in 7.25s]
12:16:34  
12:16:34  Finished running 1 view model in 0 hours 0 minutes and 19.72 seconds (19.72s).
12:16:34  
12:16:34  Completed with 1 error, 0 partial successes, and 0 warnings:
12:16:34  
12:16:34  Failure in model test_model (models\test_model.sql)
12:16:34    Runtime Error in model test_model (models\test_model.sql)
  Database Error
    Error while executing query: Artifact not found: `MainWorkspace`.`OtherLakehouse`

Notice that the name of the model in the stdout above is correct (OtherWorkspace.OtherLakehouse.dbt.test_model), but if I look at the logs, the namespace of the view it tries to create is missing the workspace_name:

create or replace view `OtherLakehouse`.`dbt`.test_model as ...

If you change the model's materialization from view to table, everything works:

{{ config(materialized='table', database="OtherLakehouse", workspace_name="OtherWorkspace") }}

select explode(sequence(1,5)) as id

Expected Behavior

Expect view models to be materialized in other workspaces, just like table models.

Steps To Reproduce

See above.

Relevant log output

Environment

- OS: Windows 11
- Python: 3.11
- dbt-adapters:
  - dbt-core: 1.11.9
  - dbt-fabricspark: 1.10.0

Additional Context

No response

[mdrakiburrahman]

Sigh...this is what I get for not actually using the feature myself yet 🙂

Would you mind doing me a favor @cheyney-w and creating some dummy dbt project in a git repo of yours that has a replica clone of what you're trying to do in production? (I.e. reads, writes, add some steps for seeding some dummy CSVs manually via Fabric UI, a self contained example).

I'll personally test it against a setup like that and ensure it works and add a test case for it.

Doing this will allow me to ensure whatever the next release has unblocks your use case.

[mdrakiburrahman]

Ah, I believe the previous PR did not add view tests, only table.

Either way, @cheyney-w if you can share a model that demonstrates how you plan to use this feature, I will make sure this bugfix works with it

[cheyney-w]

@mdrakiburrahman here's a repo that has a bunch of different scenarios: https://github.com/cheyney-w/dbt-fabricspark-cross-workspace-demo

The README.md has instructions for getting it running. Instead of relying on manual steps and CSVs of dummy data, I configured dbt seeds that can be used to create data used as sources for the models.

The following models in this repo reproduce this bug:

• view_in_other_using_source_from_main
• view_in_other_using_source_from_other

In addition, this repo shows that a similar bug exists for snapshots. See these snapshots

• snapshot_in_other_using_source_from_main
• snapshot_in_other_using_source_from_other

[mdrakiburrahman]

Ack - appreciate it, @cheyney-w!

[mdrakiburrahman]

Hey @cheyney-w,

The PR was validated against your repro project, thank you for taking the time 🙂

#182 (comment)