In certain cases, dbt-docs don't render in 0.20.0

[jaypeedevlin]

Describe the bug

Upon first loading the docs, I get a javascript error and the docs don't load. Per slack this is happening to at least one other person.

Steps To Reproduce

These are not full reproduction steps — I have a project where this happens on 0.20.0 but also projects where it does not. I'm unable to work out what's unique about the project where this 'bug' happens. This is how to reproduce on the project where it breaks:

• dbt docs serve
• dbt docs generate (if I run this command using 0.19.1 the docs load the 0.20.0 generated files without issue)

Expected behavior

The docs to load 🙂

Screenshots and log output

The following also appears in my terminal:

127.0.0.1 - - [22/Jul/2021 15:48:17] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [22/Jul/2021 15:48:17] "GET /manifest.json?cb=1626986897772 HTTP/1.1" 200 -
127.0.0.1 - - [22/Jul/2021 15:48:17] "GET /catalog.json?cb=1626986897772 HTTP/1.1" 200 -
127.0.0.1 - - [22/Jul/2021 15:48:23] code 404, message File not found
127.0.0.1 - - [22/Jul/2021 15:48:23] "GET /main.js.map HTTP/1.1" 404 -

The output of dbt --version:

dbtenv info:  Using dbt 0.20.0 (set by /Users/josh.devlin/.dbt/version).
installed version: 0.20.0
   latest version: 0.20.0

Up to date!

Plugins:
  - bigquery: 0.20.0
  - snowflake: 0.20.0
  - redshift: 0.20.0
  - postgres: 0.20.0

Additional context

If there's a way I can install the unminified JS locally so I can provide you with a more verbose error, I'm willing to help!!

[JGrubb]

Hey there, chiming in with the same issue. 0.19.1 works like a charm, 0.20.0 fails to render in the browser with the same error. I've been over the documentation YAML with a fine toothed comb but haven't found what triggers this yet. Everything else works, it's just the docs site that does not.

[jtcohen6]

Thanks for the report @jaypeedevlin!

If there's a way I can install the unminified JS locally so I can provide you with a more verbose error, I'm willing to help!!

I am decidedly not a front-end developer, but I think the move here is to run the docs site in development mode, which includes source maps that you can leverage in browser. Effectively, that looks like:

1. Clone this repo
2. Follow readme instructions to set up for development: git submodule update --init --recursive, bundle install, npm install
3. Copy your manifest.json + catalog.json files into the src/ directory
4. make dev
5. Open in browser, and use browser dev tools to find the original line with the error

I'm happy to help out here as well, if you feel comfortable sharing the artifacts privately

[jtcohen6]

Thanks to @JGrubb for sharing some error-prone artifacts! I was able to identify that the error is coming from this line:

https://github.com/dbt-labs/dbt-docs/blob/ff34ee10b385cf9ce6430ee90a9a05f21c9cc6be/src/app/services/project_service.js#L206

This is related to https://github.com/dbt-labs/dbt-docs/pull/183, which moved where the relationships test appears in the docs site: to column → from column. In so doing, it made the (reasonable) assumption that relationships tests should always have two entries in depends_on.nodes. In the problematic manifest.json, I found a relationships test that has only one entry, for some reason—the to model only, with the model model missing—even though both are present in refs. That's worth a deeper dive, as it may indicate a Core bug.

There's a larger question here, too, about the ideal display for relationships tests. As https://github.com/dbt-labs/dbt-docs/issues/204 rightly points out, it might be most interesting to display both, and adjust the language in each spot accordingly.

In any case, what we really want is to avoid crashing the entire docs site. I think one immediate fix is to change this: https://github.com/dbt-labs/dbt-docs/blob/ff34ee10b385cf9ce6430ee90a9a05f21c9cc6be/src/app/services/project_service.js#L201

To get the last-indexed item, regardless of whether there's one or two:

var model = depends_on[depends_on.length - 1];

As long as there's some model/source/snapshot/seed that the relationships test depends on, we should be in good shape.

When I reload the docs site with the same artifacts and that one line changed, everything works perfectly.

[jaypeedevlin]

Well, I at least found what the cause was from my set of artifacts.

I had some prewritten relationship tests for future models that did not yet exist — I thought I had commented them all out, but I missed one. Commenting that out fixed the issue for me!

[JGrubb]

~AHA. So, we're using BigQuery and we're using the frontroom/backroom approach where we have our staging models in a totally separate dataset (database). I only have a handful of relationships tests, and I just found the one here in a backroom model schema def:~

    columns:
      - name: order_id
        description: this is a FK to the parent Order record.
        tests:
          - not_null
          - relationships:
              to: ref('accounts_orders')  # this should be `stg_accounts_orders`, the backroom model
              field: order_id
              severity: warn

~I changed that to point to the backroom model and the docs work again (in 0.20.0)~

PEBKAC, was still on 0.19.1, they still fail in 0.20.0 so I'm totally stumped what I have done differently than every other DBT user.