I have a number of db related unit tests that started failing due to recent changes and I find it very difficult to debug them due to the masked error messages:
2024-07-03T11:56:40+0200 debug codes.vapor.application : component=server database-id=psql psql_connection_id=2 psql_error=PSQLError – Generic description to prevent accidental leakage of sensitive data. For debugging details, use `String(reflecting: error)`. [PostgresNIO] Cleaning up and closing connection.
I understand the reason for this but there really should be an opt-out I can set in unit tests, because the recommended way of dealing with these errors is not actually actionable.
The errors are thrown and handled somewhere in the stack and a priori I don't know where, so I can't just go in and add a do { } catch { String(reflecting: error) } (leaving aside that that by itself would also be quite tedious) without a lot of digging.
Or is there a way to make this possible that I'm not aware of?
It would be great to have some means to get back to the previous, "leaky" error messages even if they're not the default.
I have a number of db related unit tests that started failing due to recent changes and I find it very difficult to debug them due to the masked error messages:
I understand the reason for this but there really should be an opt-out I can set in unit tests, because the recommended way of dealing with these errors is not actually actionable.
The errors are thrown and handled somewhere in the stack and a priori I don't know where, so I can't just go in and add a
do { } catch { String(reflecting: error) }(leaving aside that that by itself would also be quite tedious) without a lot of digging.Or is there a way to make this possible that I'm not aware of?
It would be great to have some means to get back to the previous, "leaky" error messages even if they're not the default.