Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric certified for FREE! Don't miss your chance! Learn more

Reply
KobeLenjou2
New Member

Dbt Job & git repo combination does not work out of the box

Scenario:
* Create a DBT Job item in Fabric£
* Link it to a WH in the same workspace
* Save the project

* Commit to a git repo linked to the workspace
* Clone the repo in some editor and change a random ingignificat thing (add a space or so)

* Commit & Push

* Fabric will indiocate incoming changes, try to merge them

Failed to discover dependencies of the following items: *****

 

To work around:
In the repo you'll find a file called "dbt-content.json" that defined the link to the WH you defined before. It looks something like this:

 "properties": {
        "type": "DataWarehouse",
        "typeProperties": {
          "workspaceId": "cda7811b-a4cf-42b9-9967-ec6f3da25cc2",
          "artifactId": "3483f7d2-1a59-448f-b008-3cc30bd5dd78"
        }
      }
    }

Now, change this to

"properties": {
        "type": "DataWarehouse",
        "typeProperties": {
          "workspaceId": "00000000-0000-0000-0000-000000000000",
          "artifactId": "0bd5dd78-3cc3-b008-448f-1a593483f7d2"
        }
      }
    }

The many zeroes indiocate the current workspace, and the artifact id is the 'logical id' instead of the 'physical id'

This is clearly a bug on Fabric end, but we can get around it for now.

1 ACCEPTED SOLUTION
bariscihan
Resolver II
Resolver II

Hi,

Thanks for sharing the detailed repro steps — this looks like a Fabric-side Git integration / dependency resolution issue for dbt Job items.

What’s failing
After committing the dbt Job definition to a Git-connected workspace and then pushing even a trivial change from an external editor, Fabric detects incoming changes but fails during merge with:

“Failed to discover dependencies of the following items: …”

From what I’m seeing, the root cause is the way the dbt job definition stores the Data Warehouse reference in dbt-content.json:

  • workspaceId and artifactId are stored in a way that Fabric can’t reliably resolve after the Git roundtrip (especially when the repo is merged back into the workspace).

  • The fix is to use the logical identifiers that Fabric expects for dependency discovery.

Workaround / Fix
In your repo, open dbt-content.json and update the warehouse reference as follows:

  1. Set workspaceId to all zeros to indicate “current workspace”:
    00000000-0000-0000-0000-000000000000

  2. Use the logical artifactId (not the physical one). In practice, this can appear like a re-ordered GUID format compared to what was originally saved.

After committing this change and merging again, Fabric should be able to resolve the dependency and complete the Git sync.

Reference (official documentation)
Microsoft’s REST API docs for dbt job definitions show this exact pattern (zero workspaceId + logical IDs). You can use this as the authoritative reference:
https://learn.microsoft.com/en-us/rest/api/fabric/articles/item-management/definitions/dbtjob-defini...

Suggestion
Until this is fixed in Fabric, I’d recommend keeping the dbt job definition aligned with the documented schema before merging back into the workspace. If you can share whether the target Warehouse is in the same workspace (and whether you’re using a specific branch policy), I can also suggest a safer Git workflow to avoid re-triggering the dependency discovery failure.

Hope this helps — please let me know if the merge still fails after updating dbt-content.json.

View solution in original post

3 REPLIES 3
v-kpoloju-msft
Community Support
Community Support

Hi @KobeLenjou2

Thank you for reaching out to the Microsoft Fabric Community Forum. Also, thanks to @bariscihan@ssrithar,  for those inputs on this thread.

Has your issue been resolved? If the response provided by the community member @bariscihan@ssrithar,   addressed your query, could you please confirm? It helps us ensure that the solutions provided are effective and beneficial for everyone.

Hope this helps clarify things and let me know what you find after giving these steps a try happy to help you investigate this further.

Thank you for using the Microsoft Community Forum.

bariscihan
Resolver II
Resolver II

Hi,

Thanks for sharing the detailed repro steps — this looks like a Fabric-side Git integration / dependency resolution issue for dbt Job items.

What’s failing
After committing the dbt Job definition to a Git-connected workspace and then pushing even a trivial change from an external editor, Fabric detects incoming changes but fails during merge with:

“Failed to discover dependencies of the following items: …”

From what I’m seeing, the root cause is the way the dbt job definition stores the Data Warehouse reference in dbt-content.json:

  • workspaceId and artifactId are stored in a way that Fabric can’t reliably resolve after the Git roundtrip (especially when the repo is merged back into the workspace).

  • The fix is to use the logical identifiers that Fabric expects for dependency discovery.

Workaround / Fix
In your repo, open dbt-content.json and update the warehouse reference as follows:

  1. Set workspaceId to all zeros to indicate “current workspace”:
    00000000-0000-0000-0000-000000000000

  2. Use the logical artifactId (not the physical one). In practice, this can appear like a re-ordered GUID format compared to what was originally saved.

After committing this change and merging again, Fabric should be able to resolve the dependency and complete the Git sync.

Reference (official documentation)
Microsoft’s REST API docs for dbt job definitions show this exact pattern (zero workspaceId + logical IDs). You can use this as the authoritative reference:
https://learn.microsoft.com/en-us/rest/api/fabric/articles/item-management/definitions/dbtjob-defini...

Suggestion
Until this is fixed in Fabric, I’d recommend keeping the dbt job definition aligned with the documented schema before merging back into the workspace. If you can share whether the target Warehouse is in the same workspace (and whether you’re using a specific branch policy), I can also suggest a safer Git workflow to avoid re-triggering the dependency discovery failure.

Hope this helps — please let me know if the merge still fails after updating dbt-content.json.

ssrithar
Resolver III
Resolver III

Hi @KobeLenjou2 ,

 

The workaround appears to be legitimate based on official Microsoft documentation. In the Microsoft Fabric REST API documentation for dbt job definitions, there's an official example showing exactly this pattern please refer and hence the same might work here. Since Fabric is evolving quickly we might see the changes in GA faster

 

If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!

 

API dbt

Helpful resources

Announcements
Join our Fabric User Panel

Join our Fabric User Panel

Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.

February Fabric Update Carousel

Fabric Monthly Update - February 2026

Check out the February 2026 Fabric update to learn about new features.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.