connect() stalls under Perry-native on Linux (EINPROGRESS, 'connect' never fires); raw net.createConnection works

[proggeramlug]

Summary

Under a Perry-compiled binary on Linux x86_64, connect() to a local MySQL hangs until connectTimeoutMs and fails with connection timeout after 10000ms. strace shows the TCP socket reaches connect() = EINPROGRESS but the 'connect' event never fires, so the handshake never starts.

The same code works in every other combination:

• Node.js on the same box → connects.
• Perry-native on macOS (arm64) → connects (our full service e2e passes natively on macOS).
• A minimal raw net.createConnection compiled by the same Perry on the same Linux box → connects (even with 'data'/'error' listeners attached and wrapped in top-level await).

So raw net works under Perry-native-Linux, but the driver's connect() path does not — the driver's sock.on('connect', …) callback (connection.ts ~L418, after openSocket at L360) is never invoked.

Repro

net-test.ts (raw stdlib) → CONNECTED natively on Linux:

import * as net from 'net';
const s = net.createConnection(3306, '127.0.0.1');
s.on('connect', () => { console.log('CONNECTED'); s.end(); process.exit(0); });
s.on('data', () => {});                         // even with a data listener
s.on('error', (e) => { console.log('ERR', String(e)); process.exit(1); });
setTimeout(() => { console.log('TIMEOUT'); process.exit(2); }, 5000);

drv-test.ts (this driver) → TIMEOUT natively on Linux (CONNECTED under Node):

import { connect } from '@perryts/mysql';
const c = await connect('mysql://optiq:***@127.0.0.1:3306/optiq');
console.log('CONNECTED', JSON.stringify((await c.query('SELECT 1 AS ok')).rows[0]));
await c.close();

Both compiled with perry compile <file>.ts -o <bin> and run on the same host.

strace (the driver binary)

socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 9
connect(9, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
... no further activity on fd 9 ...
write(2, "Error: connection timeout after 10000ms", 39)

The non-blocking connect() completion (epoll EPOLLOUT) is apparently never observed for the driver's socket, though it is for a bare net.createConnection.

Environment

• perry 0.5.1125 and 0.5.1129 — both reproduce.
• @perryts/mysql github HEAD; MySQL 8.4.9 (user is mysql_native_password, require_secure_transport=OFF, bound 127.0.0.1); Ubuntu 26.04 x86_64; clang 21.
• The mysql CLI and a raw TCP connect to 127.0.0.1:3306 both succeed instantly; MySQL's general log shows no connection attempt from the driver binary (it never completes the handshake).

Impact

Blocks any Perry-native Linux service using the driver. Our optiq-engine (fastify + this driver) compiles and runs end-to-end as a native binary on macOS and under Node on Linux, but the native Linux binary can't reach MySQL because of this. Likely a Perry Linux net interaction rather than a driver-logic bug (raw net works), but filing here since it's observed through the driver — please reclassify to perry if that's the right home.

[proggeramlug]

Root-caused: it is not connect() — connect + reading the 94-byte greeting both work natively. The driver computes the auth response and calls sock.write() for the HandshakeResponse41 from inside its 'data' handler, and that write is silently dropped by Perry on Linux (no write() syscall) → MySQL returns Got timeout reading communication packets. Minimal repro + strace filed at PerryTS/perry#5021. Empty-password connections work (zero-length auth response avoids the failing write).

[proggeramlug]

Re-verified after the perry-side fix. perry#5021 is genuinely fixed — a socket.write() from a 'data' handler now reaches the wire (sendto) in published perry 0.5.1182. But @perryts/mysql 0.1.5 password auth still times out under a Perry-native Linux binary, due to two issues in the driver's Perry handling:

1. deferWrites never activates under Perry. It's gated on FORCE_DEFER_WRITES || !isNodeLike(), and isNodeLike() tests typeof process.versions.node === 'string' — but a Perry-compiled binary reports process.versions.node = "22.0.0", so the driver mis-detects Perry as Node and leaves deferWrites = false. It then takes the direct st.sock.write() path, whose bytes are dropped.

2. Even forced on, the deferred flush never runs. With deferWrites = true, flushWriteQueue() is never called — the setTimeout(() => flushWriteQueue(id), 0) scheduled from inside the 'data' handler doesn't fire under the native binary (no flush log, no sendto), so the queued HandshakeResponse41 is never written and MySQL replies Got timeout reading communication packets.

Empty-password connections work (zero-length auth response ⇒ the failing write path isn't exercised). Repro env: mysql_native_password user with a password, perry 0.5.1182, @perryts/mysql 0.1.5, MySQL 8.4, Ubuntu 26.04 x86_64. Happy to attach the instrumented traces.

[proggeramlug]

Update with driver 0.1.7: the Perry detection is now correct (isPerry() via process.versions.perry → deferWrites enabled) and the setInterval flush pump fires. But password auth still times out — the pump's write (flushWriteQueue → CONN_STATES.get(id).sock.write(bytes)) emits no sendto. Reduced to a residual Perry codegen bug (filed PerryTS/perry#5540): a socket.write() through a Map-stored object property from a timer callback is dropped on Linux, while a top-level-const socket write from the same context reaches the wire. So the driver fix is the right shape; it's now blocked on perry#5540, not the driver.