"Could not convert to String: <null>" error with empty strings

[juanLovera]

Describe the bug

After upgrading to postgres-nio 1.5.0, our server started crashing with a bunch of errors like this:

[ ERROR ] invalid field: stripe_id type: String error: typeMismatch(Swift.String, Swift.DecodingError.Context(codingPath: [], debugDescription: "Could not convert to String: <null>", underlyingError: nil)) [request-id: 4A11F25B-AD9C-43EC-BC9B-996A434DBAF2]

The indicated field is non-null on Postgres and non optional on Swift. I discovered that this is happening when the field's value is an empty string, so it would seem like empty strings are being treated as null values.

To Reproduce

1. Create non-null text field in postgres.
2. Create Vapor model and connect with that field (with a non optional var)
3. Add a new row with an empty string.
4. Try to fetch that row in Vapor -> it should crash.

Expected behavior

It should return the empty string instead of crashing.

Vapor 4.32.0
Fluent 4.0.0
Postgres-nio 1.5.0
Postrges 11.5

[fabianfett]

Hi @juanLovera, as you may know a lot was changed for 1.5.0. See #135. The question now is: Is this a bug in PostgresNIO or is this a bug in a layer above that was only made visible through the changes in 1.5.0.

Would you be able to run your Fluent query as plain SQL with a plain PostgresConnection against your database and see if the returned rows are correct? This would help a ton.

[juanLovera]

@fabianfett Just ran the raw query and the returned rows are correct. Also compared the generated query using 1.5.0 vs 1.4.3 and they're the same. Let me know if I can help with anything else. Thanks.

[MihaelIsaev]

We see same bug in PostgresBridge, empty strings became NULLs, it is explicitly visible during inserts.

Is this a bug in PostgresNIO or is this a bug in a layer above

@fabianfett Seems that it is bug in postgres-nio since after rollback to 1.4.4 everything works fine. We decided to stick to 1.4.4 for now.

[fabianfett]

@MihaelIsaev @juanLovera We already have identified the issue and are working on a fix. Should be up in latest an hour.

[fabianfett]

@MihaelIsaev @juanLovera could you please verify the pr #144 resolves your issue?