Rider 2024.2 database tools: connection keep-alive and idle timeout options after migrating data sources

Answer

The idle‑connection behavior in Rider 2024.2 is controlled by three independent layers:

1. Rider data‑source options – Auto-disconnect after (seconds) and Run keep-alive query each (seconds) on the Options tab.
2. JDBC driver properties – socketTimeout, loginTimeout, and optional idleTimeout set on the Advanced tab as JDBC URL parameters.
3. Server‑side limits – PostgreSQL settings such as idle_in_transaction_session_timeout, tcp_keepalives_idle, etc.

Confirmed facts (from Rider 2024.2 documentation and the research brief)

• Auto-disconnect after defaults to 0 (disabled). When set to a positive value, Rider closes the connection after that many seconds of inactivity and logs a message like "Closing idle connection to PostgreSQL due to auto-disconnect".
• Run keep-alive query each defaults to empty (disabled). When a query (e.g., SELECT 1) and interval are supplied, Rider sends that SQL at the interval and logs "Executing keep-alive query: SELECT 1".
• JDBC driver defaults for the PostgreSQL driver are socketTimeout=0 (infinite), loginTimeout=0, and no idleTimeout unless explicitly added. Changing these values requires reconnecting the data source (or restarting Rider) for them to take effect.
• Migration of a data source from Rider 2023.3 to 2024.2 preserves the XML configuration; option names and defaults are unchanged, so existing values are retained unless the data source is recreated.
• Rider’s IDE log (Help → Diagnostic Tools → Show Log in Explorer) records client‑side disconnects and keep‑alive attempts as described above. JDBC‑level timeouts appear as "Communications link failure" or "Socket timeout expired" stack traces.

Likely explanation for the observed stall

If the stall occurs after a period of IDE inactivity and the log shows neither an auto‑disconnect nor a keep‑alive entry, followed by a JDBC communications error, the termination is most likely server‑side (PostgreSQL idle timeout or TCP keepalive) or caused by a JDBC socketTimeout that was not overridden. Conversely, if you see an auto‑disconnect log entry just before the stall, the client‑side Rider setting is the cause.

Steps to verify and adjust for your case

1. Open the data source → Options tab and note the current values of Auto-disconnect after and Run keep-alive query each.
2. Enable detailed logging: Help → Diagnostic Tools → Show Log in Explorer and keep the idea.log file visible.
3. Set a test configuration, for example:
   • Auto-disconnect after = 300 seconds (5 min)
   • Run keep-alive query each = SELECT 1 every 60 seconds
   Apply the changes and reconnect the data source.
4. Leave Rider idle for >5 minutes, then run a query or refresh the schema.
5. Immediately check idea.log:
   • If you see "Closing idle connection to PostgreSQL due to auto-disconnect" → the stall is caused by Rider’s auto‑disconnect; increase the value or disable it.
   • If you see "Executing keep-alive query: SELECT 1" at regular intervals but still get a JDBC error → the keep‑alive is not reaching the server (check network/firewall).
   • If there is no auto‑disconnect or keep‑alive message and the log shows a "Socket timeout expired" or "Communications link failure" stack trace → the issue is JDBC or server‑side.
6. To isolate server limits, temporarily disable both Rider options (set auto‑disconnect to 0 and clear keep‑alive), reproduce the stall, and verify whether the log shows only a JDBC communications failure. If so, examine PostgreSQL parameters:
   • SHOW idle_in_transaction_session_timeout;
   • SHOW tcp_keepalives_idle;
   Adjust those settings on the server or increase the JDBC socketTimeout (e.g., add ?socketTimeout=0 to the URL) and reconnect.

Missing diagnostic detail that would change the recommendation

We need to know the approximate idle period after which the stall occurs (e.g., 2 minutes, 10 minutes, 30 minutes). If the stall happens well before any reasonable Rider auto‑disconnect value you might set, the cause is almost certainly server‑side or JDBC; if it aligns with a specific interval you can tune, adjusting Rider’s auto‑disconnect or keep‑alive is the direct fix.