ValueError when column_types defined in dbt_project.yaml but null/empty shows up in seed file

[jasonwang592]

Describe the bug

dbt seed --full-refresh caused the issue and resulted in max() arg is an empty sequence.

Steps To Reproduce

Provide seed definitions in dbt_project.yaml with something along the lines of :

seeds:
  project_name:
    enabled: true
    schema: seeds_schema
    foo_barr_seed:
      column_types:
        column_that_breaks: varchar(128)

Then create a seed file where at least one row has an empty string "" in the column_that_breaks column.

The final line in the debug log file from dbt cloud shows that a null value isn't being handled well in Python:
max_len = max(lens) if lens else 64

Expected behavior

dbt seed should either handle null/empty values when a column_type is defined or exit with a more graceful message

Screenshots and log output

Full log attached. Screenshot of the last lines of the stack trace as well as the error below:
debug (1).log

System information

Which database are you using dbt with?

• postgres
• redshift
• bigquery
• snowflake
• other (specify: ____________)

The output of dbt --version:

installed version: 0.16.0
   latest version: 0.16.0

Up to date!

The operating system you're using:
macOS Catalina
10.15.3

Also fails in dbt cloud.

The output of python --version:
Python 3.7.3

Additional context

From the #support channel in the dbt slack community: https://getdbt.slack.com/archives/C2JRRQDTL/p1585243307097400

As an addition, thanks to you all for maintaining an amazing and responsive slack community. I always have confidence that I'll get help whenever I have an issue with dbt. Much love from Envoy!

[beckjake]

triage note: we can fix this issue by just making lens a list comprehension instead of a generator expression, but this also exposes a need to unit test these conversion methods - this seems like an easy fix to inadvertently revert!

[drewbanin]

Thanks for this really thorough report @jasonwang592!

@beckjake should we sneak this in for 0.16.1 or is this an 0.17.0 fix? I'm mostly curious if it's an 0.16.0 regression or a long-standing bug

[beckjake]

@drewbanin If it's a regression, it's of the "other changes to dbt exposed an existing bad behavior" variety, because the code in question hasn't changed. The user on slack reported it in the context of "I updated to dbt 0.16.0 and ...", and it's believable that the issue was exposed by the changes to how dbt handles seeds with user-defined types in 0.16.0.

I think we should get it into 0.16.1 regardless - it seems like it's a pretty trivial fix with low/no risk.

[drewbanin]

Cool, sounds good to me, just added this to the 0.16.1 milestone - let's make it happen

[beckjake]

Fixed in #2255