[CT-64] Model meta missing from top-level node meta in manifest

[troyel]

Describe the bug

A clear and concise description of what the bug is. What command did you run? What happened?

Steps To Reproduce

Add any meta tags to a model. e.g.

{{ config(
    meta = {
    'single_key': 'override'
    }
    ) 
}}

Or similarly specified using .yml schemas.

Expected behavior

Expect this to show up like it does in "Exposures" as a table detail formatted key-value list (also like tags does)

How it looks in a model:

How it is expected to look (like it does implemented the same in an exposure):

Screenshots and log output

The output of dbt --version:

installed version: 0.21.0
   latest version: 1.0.0

Plugins:
  - spark: 0.21.0
  - postgres: 0.21.0
  - redshift: 0.21.0
  - bigquery: 0.21.0
  - snowflake: 0.21.0

[jtcohen6]

@troyel Thanks for opening!

I think this is actually a bug in dbt-core, stemming from the config/property changes in v0.21. When defining meta for a model, the key is added (and resolved) to config.meta, but it isn't mirrored to the top-level meta key on the model object.

If I check in manifest.json, I see:

"model.my_project.my_model": {
  "config": {
    "enabled": true,
    "alias": null,
    "schema": null,
    "database": null,
    "tags": [],
    "meta": {
      "my_key": "my_value"
    },
  },
  "meta": {},
}

@gshank Do you have a sense of where that mirroring ought to be happening? I do think it's reasonable for downstream metadata consumers (including the dbt-docs site) to expect those values in node.meta, rather than the more deeply nested node.config.meta.

I'm going to transfer this one to dbt-core

[turbo1912]

related to the same problem, consumers of the graph jinja variable also have access to meta tag information of a model in graph["model_name"].config.meta rather than graph["model_name"].meta

[gshank]

The 'meta' dictionary is copied to the top-level node in core/dbt/parser/base.py, update_parsed_node_config. I would have thought that would be called for config in a model. Clearly there's some hole here.

[jeremyyeo]

@jtcohen6 continuing this from dbt-labs/dbt-docs#230 - is there some sense in not having to duplicate the meta config to the top level meta for this?

Just thinking out loud since typically manifest.json gets to be quite large plus now we have to maintain logic that does the node.config.meta bits as well as the node.meta bits. On top of that we may introduce new config that we similarly want to display in the future thus having to duplicate them too. Feels a bit wasteful. But I suppose as you pointed out we want to keep to some expected behaviour (editors note: but at the cost of manifest size and additional complexity) and I'm certainly missing additional context on why we need to have this meta repeated.

[saraleon1]

+1 in dbt Core version 1.0.1 in dbt Cloud

User wants to add 'owner' and 'group' meta fields at the model level, but they are not visible in the 'details' section of the docs site.

Let me know if there's any additional context I can provide!