Race Condition Issue in PostgreSQL SSL Connection Process

lib/connection.js から始め、RDS Proxy 経由の PostgreSQL 接続中に stream.connect()、TCP の 'connect' イベント、requestSsl()、および stream の 'data' リスナーがどのように連携するかを追跡します。可能であれば断続的な TLS 切断を再現し、直接の PostgreSQL 接続と比較します。完了条件は、競合状態の仮説を確認または棄却し、具体的な緩和策または修正を文書化することです。

I have been encountering "Error: Client network socket disconnected before secure TLS connection was established" errors recently without any specific cause when connecting to PostgreSQL through RDS Proxy. These errors occur intermittently, making them difficult to reproduce consistently.
After examining the code in the pg module's lib/connection.js file, I suspect there is a race condition issue between the TCP connection and TLS connection process. The architecture of the connection flow appears problematic:

• Client initiates TCP connection (stream.connect(port, host))
• When TCP connection succeeds, a 'connect' event is emitted
• However, the code for SSL/TLS connection is not directly linked to the 'connect' event
• Instead, logic to wait for the server's SSL support response is set up separately (stream.once('data', function (buffer) {...})

This design creates potential timing issues because:

• There's no explicit synchronization between the TCP connection establishment and when requestSsl() is called
• The SSL handshake process depends on event listeners that operate asynchronously
• When working with RDS Proxy as an intermediary layer, these timing sensitivities may become more problematic

I've verified this by testing direct connections to PostgreSQL without RDS Proxy, which work consistently. The issue only manifests when connecting through the proxy layer.
Please check if my understanding of this potential race condition is correct, and if there are any recommended approaches to mitigate this issue.