[Bug] dbt docs fails to load on browser with javascript TypeError

[rudo-ro]

Is this a new bug in dbt-core?

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

Current Behavior

we are currently hosting the dbt docs generate output on s3 and viewing dbt docs as a static page via index.html. this worked great however after a seemingly benign pull request the index.html fails to render the data, stuck in "loading" state.

we have isolated the change to a single commit that compiles correctly with functioning models and source files.

able to replicate with the manifest.json locally attempting to load using dbt docs serve

Expected Behavior

webpage loads OR dbt project parsing highlights issue

Steps To Reproduce

I'm unsure how to reproduce this issue without proviuding our manifest.json file?

Relevant log output

stacktrace from chrome developer tools

#s3
(index):47 TypeError: p.startsWith is not a function
    at (index):41:81837
    at n ((index):41:29079)
    at xt ((index):41:5845)
    at Do ((index):41:38691)
    at Function.find ((index):41:29098)
    at (index):41:81790
    at st ((index):41:4751)
    at Function.la ((index):41:41030)
    at (index):41:80711
    at (index):47:95585 'Possibly unhandled rejection: {}'

#local
TypeError: p.startsWith is not a function
    m http://localhost:8080/:41
    n http://localhost:8080/:41
    xt http://localhost:8080/:41
    Do http://localhost:8080/:41
    Zt http://localhost:8080/:41
    loadProject http://localhost:8080/:41
    st http://localhost:8080/:41
    la http://localhost:8080/:41
    loadProject http://localhost:8080/:41
    d http://localhost:8080/:47
    d http://localhost:8080/:47
    $digest http://localhost:8080/:47
    $apply http://localhost:8080/:47
    x http://localhost:8080/:47
    A http://localhost:8080/:47
    onload http://localhost:8080/:47
Possibly unhandled rejection: {}

Environment

- OS:debian:12.5
- Python: 3.11.9
installed via python:3.11.9-slim-bookworm 

- dbt:

dbt-adapters==1.3.1
dbt-common==1.4.0
dbt-core==1.8.3
dbt-extractor==0.5.1
dbt-semantic-interfaces==0.5.1
dbt-snowflake==1.8.3

Which database adapter are you using with dbt?

snowflake

Additional Context

No response

[dbeatty10]

Thanks for reaching out @rudo-ro !

The error message you shared looks like it might be coming from here (introduced in dbt-labs/dbt-docs#425).

What was in the commit that you isolated it to? Was it a related to a new or modified data test column, by any chance?

If you can provide that code that triggered it, that might help us replicate the issue.

[rudo-ro]

thanks @dbeatty10

yes the code included snippets such as:

models:
  - name: name_here
    description: ''
    data_tests:
      - unique:
          column_name: "x_id || y_id"
      - not_null:
          column_name: 
            - x_id
            - y_id

I rebuilt the project without this commit and it's working.

[dbeatty10]

Ah, I see what you are saying @rudo-ro.

This isn't the way I'd expect the unique and not_null data tests to be configured though. If you run your tests and then look at the relevant SQL in target/run/ you'll see it generates incorrect logic:

select ['x_id', 'y_id']
from analytics_dev.dbt_dbeatty.name_here
where ['x_id', 'y_id'] is null

Did you try something like this instead?

models:
  - name: name_here
    columns:
      - name: x_id
        data_tests:
          - not_null
          - unique
      - name: y_id
        data_tests:
          - not_null
          - unique

When I used the following example data, it worked the way I would expect:

models/name_here.sql

select 1 as x_id, 2 as y_id union all
select 1 as x_id, 2 as y_id union all
select null as x_id, null as y_id

dbt run -s name_here
dbt test
dbt docs generate
dbt docs serve

[rudo-ro]

thank you @dbeatty10 !

okay this is working!

I wonder if some kind of parsing warning enhancement would be helpful here for future users?

[dbeatty10]

I wonder if some kind of parsing warning enhancement would be helpful here for future users?

Good idea about doing some kind of warning if dbt can detect that something is definitely off 💡

In this case, we've chosen for dbt to be very open-ended and allow strings, lists and dictionaries to be configured underneath data_tests: because users are free to create their own custom data tests as well. So I don't see a good way for us to do that kind of detection.

I think the code example that added confusion in your case was this one: https://docs.getdbt.com/reference/resource-properties/data-tests#test-an-expression

So I've opened this documentation issue to see if we can update it to be more clear: dbt-labs/docs.getdbt.com#6436

Since we got to the bottom of things, I'm going to close this issue in favor of updating our docs.