Why does the data received from PostgreSQL break?

Question

PostgreSQL

Welcome all.
I have exhausted my ability to find a solution to the problem and I beg you to help :)
There is a project that has been truncated to the minimum configuration that allows you to reproduce the bug: https://github.com/TerminusMKB/moidelishki
The project has one single controller that, when requested, requests and returns data about the same user in the database. At the first request to itself, it returns the correct data:

{"id":2,"testArray":"{1,2,3}","testTimestamp":"2016-01-01 00:00:00+03"}

At the tenth time (conditionally, but somewhere in that area) it starts to give out the following:

{"id":2,"testArray":"{\"1\",\"2\",\"3\"}","testTimestamp":"2016-01-01 00:00:00+03"}

Those. starts wrapping array elements in quotation marks for some reason.
What is known:
1) Reproducible with PostgreSQL 9.3 and 9.4
2) Only reproducible when using a jdbc driver older than 9.4-1201-jdbc41. There are no problems with this version.
3) Changed the connection pool from c3p0 to Vibur - didn't help 4
) Changed Spring and Hibernate versions - didn't help
appeared first in its own defined UserType. There I looked at what was coming to the class from the database and at a certain moment I saw broken data. Now the problematic field has a String type just for viewing convenience.
There are, as it were, plans to update the database for a fresher version, and the driver, respectively, is more relevant, then this question simply baffles.
What could be the problem?

Answer 1

The sniffer (Wireshark) showed the following:
1) With jdbc 9.4-1201-jdbc41, one request is sent each time. And every time a complete correct answer comes from the database.
The request in the sniffer dump looks like this:

Type: Parse
Length: 169
Statement:
Query: select user0_."id" as id1_0_, user0_."testArray" as testArra2_0_, user0_."testTimestamp" as testTime3_0_ from "public"."users" user0_ where user0_."id" in (2)
Parameters: 0

2) With older versions of jdbc, at the beginning (on the first attempts) the same request is made, only with the Statement:

Type: Parse
Length: 169
Statement: S_2
Query: select user0_."id" as id1_0_, user0_."testArray" as testArra2_0_, user0_."testTimestamp" as testTime3_0_ from "public"."users" user0_ where user0_."id" in (2)
Parameters: 0

3) In a situation where a bug is visible, jdbc no longer sends the above request, but the following (as I understand it, several commands at a time):

Type: Bind
Length: 21
Portal:
Statement: S_2
Parameter formats: 0
Parameter values: 0
Result formats: 3
   Format: Binary (1)
   Format: Binary (1)
   Format: Binary (1)

Type: Execute
Length: 9
Portal:
Returns: all rows

Type: Sync
Length: 4

And in response, it receives data that is already difficult to evaluate with the eyes in the dump - they do not come in text.
PS: The problem was solved by setting the jdbc parameter of the preparedStatementCacheQueries driver to 0. Disabling the cache led to the fact that the driver stopped using prepared statements for queries at all and each time sends the request in full, as in version 9.4-1201-jdbc41. So-so solution, in fact, because I will have to try again, what happens if I want to use prepared statements myself.

Answer 2

1) Try throwing away the lombok, suddenly the problem is in it and the hell knows how he hung the getter / setter there.
2) Try to look at the traffic between Java and the database with a sniffer. Are the request and response exactly the same each time?
2.1) If the problem is with the fact that such a broken answer arrives from the database, then dig in the direction of the problem with the database.
2.2) If a request from Java arrives at a certain moment of the curve, then dig further into Java itself.

Answer 3

Congratulations. This is a JDBC bug and ARRAY deserialization, it was the same thing at one time, but for a long time.
At first I solved it with a crutch, then I updated the driver to 9.4.1210. Now everything seems to be normal.