DataGrip introspection error on macOS Sonoma
I'm struggling to get Datagrip to work with a Postgres DB on AWS following the Xmas break. All was working fine 10 days ago.
I'm now on 2023.3.2 but it seems like there are issues with:
a) database introspection - this seems to fail with this message: “Error encountered when performing Introspect database stockmodel schema aws_commons (names): An I/O error occurred while sending to the backend. An I/O error occurred while sending to the backend. This connection has been closed. and 694 duplicate reports”
b) holding a connection: I get a lot of “An I/O error occurred while sending to the backend. This connection has been closed…” messages
I'm not sure if the two are linked or not.
I have tried Diagnostics → Force Refresh
Any suggestions would be great please.
Please sign in to leave a comment.
Please upload the idea log from Help - Show Log in FIles to our FTP server
https://uploads.jetbrains.com/
Include the upload id in your reply.
We'll have a look.
Hi
Done as per: Upload id: 2024_01_04_8UoJbtd3eNkhGiPdmPBSz3 (file: idea.log)
Hi Steve,
There seem to be connectivity issues with your database as there's no response from the database server when we're querying data to update the database object tree in DataGrip
2024-01-04 11:10:48,298 [ 110158] WARN - #c.i.d.u.ErrorHandler - An I/O error occurred while sending to the backend.
An I/O error occurred while sending to the backend.
The SQL statement:
2024-01-04 11:11:43,998 [ 165858] INFO - #c.i.s.GitSettingsLog - Updated position of cloud from 4d7005f3 to b07b83de: FORCED
2024-01-04 11:11:46,536 [ 168396] WARN - #c.i.d.d.BaseDatabaseErrorHandler$IOErrorInfo - Operation timed out
java.net.SocketException: Operation timed out
Please check if there are no issues with the database connectivity on the AWS end.
The database connection is fine:
The database is locked down on AWS but visible to me and other colleagues using the AWS VPN Client. I can run simple queries and create tables that have never existed but I cannot run more complex queries or recreate tables that have previously existed.
Nothing has changed in the setup since my connections in late December other than an update to DataGrip.
A colleague is still using 2023.2.1 and this is working fine with the same AWS DB and connection method.
I ran tests on the same AWS database using Visual Studio Code:
=> so I am 99.9% sure this is a DataGrip issue.
Do you have any other suggestions? How would I go about reverting DataGrip to an older version?
Just as an update - I am on a Mac running Sonoma - my colleague who has a normally functioning DataGrip is running on Windows 10.
Here are the error messages I get when it fails to run a simple query:
Thanks for the update.
Do you recall what version you had before upgrading? Also, do your colleagues work with the same pg database running on AWS?
You can install a previous version of DataGrip as a separate installation. For better versioning management, our Toolbox can make it easy for you:
https://www.jetbrains.com/toolbox-app/
I can suggest to observe this behavior in another version, and let me know your results. We'll take it from there.
Hi Aleksandr,
I can't be sure but my previous version was 2023.1.2 I think. I've tried 2022.2.5 and 2023.1.2 and neither make any difference (I still get the previous errors). Meanwhile I have reverted back to 2023.3.2
My colleagues work with the exact same pg database running on AWS - I have checked again and can confirm that they don't get these errors.
The steps that happen for me are:
Running long queries works fine in DBVisualizer, VSCode etc using the same AWS database.
Thanks for any further suggestions
Steve
I have checked with our dev team to confirm if there were any changes made to the introspection logic of Postgres data sources or how we handle the connection. They have not made any changes in those modules throughout the 2023.X version releases.
The reason for 3. is slow fetching performance that could be caused by unstable connection. When you're running lightweight queries, taking milliseconds to finish, it could be not easy to spot a connectivity error as they are swift in terms of execution time. Unlike such queries, introspection queries are more complex in their logic and usually take more time to complete. In such cases, connectivity issues are becoming more obvious due to the duration of query execution and, as a result, can throw errors while running the query. This is the reason why we asked you to check your connection, namely your VPN tunnel, and see if there are no connection drops / resets indicated in the client log while introspection is running. To double-check this, you can additionally inspect the database log for the following records, correlating with the time you ran the introspection, or have us inspect the log
`[2024-01-09 17:23:09] Disconnected`
`[2024-01-09 17:23:10] Connected`
Hi Aleksandr,
Thanks for checking all of this and you were quite correct, it was my connection - seemingly the AWS VPN was doing something strange for these more complex queries and the introspection which it wasn't doing before the Xmas break.
I've since updated my use of the VPN and this has resolved the issue. Many thanks for the detailed responses - much appreciated.
Good to hear it's working now, and the issue is permanently fixed.