SQL compilation error: Insert value list does not match column list expecting 15 but got 14

[adrianba27]

dbt artifacts macro insert_into_metadata_table.sql is making any dbt command fail with the following error.
SQL compilation error: Insert value list does not match column list expecting 15 but got 14

Talking to dbt they had this to say:

It looks like this error is stemming from the dbt-artifacts package, more particularly it may be related to the insert_into_metadata_table.sql macro.

Insert value list does not match column list: the SQL statement consists of first a list of columns then a list of values, these two do not match.
Column count doesn't match value count: the problem is that the number of listed values is not the same as the number of listed columns.

Macro:

{% macro insert_into_metadata_table(database_name, schema_name, table_name, content) -%} {% if content != "" %} {{ return(adapter.dispatch('insert_into_metadata_table', 'dbt_artifacts')(database_name, schema_name, table_name, content)) }} {% endif %} {%- endmacro %}

Is this a known issue?

This is our current env:

Running with:

1. dbt=1.3.4
2. calogica/dbt_expectations = 0.8.1
3. brooklyn-data/dbt_artifacts = 2.2.3
4. dbt-labs/metrics= 1.3.2
5. dbt-labs/codegen= 0.9.0
6. calogica/dbt_date=0.7.2
7. dbt-labs/dbt_utils=1.0.0

[jecolvin]

Hi Adrian,

We apologize for this, we pushed a release that ended up having a bug not caught by our integration tests. We've rolled it back so if you rerun dbt deps you shouldn't have this issue any longer!

[adrianba27]

Hi @jecolvin,

First of all, we really appreciate the great work you are doing with this package.

However, that didn't fix the issue, since we had already dbt artifacts models that where changed due to the 2.2.3 release. We had to manually drop the extra attributes that 2.2.3 added to the dbt artifact models. Costing us 1 day of development.

[michaellynton]

I'm in the same boat today. Now I need to go manually drop columns that got added yesterday.

Do you mind sharing all the columns that you needed to drop?

[adrianba27]

Hi @michaellynton,

We found that the fastest way was to drop the message column on the {object}_execution tables. We did a snowflake query to find them all and drop them.

Good luck!

[michaellynton]

Many thanks for the pointer!