[robobun]

Problem

• tls.connect({ socket }) over a still-connecting net.Socket never emits 'connect' on the TLSSocket, only 'secureConnect', so a 'connect' listener that starts the conversation never runs. Node v26.3.0 emits it when the TCP connect completes.
• Socket.prototype.connect (src/js/node/net.ts:2082) starts TLS from the wrapped socket's 'connect' and does not re-emit it.
• end() before that connect found no handle: 'finish' fired at once and no FIN was sent.

Fix

• Emit 'connect' from the wrapped socket's 'connect', after the TLS handle is attached, as node's TLSSocket._init does (wrap.js#L964-L973). The branch that runs TLS over the stream at once (connecting named pipe, parked write, TLSSocket) gets the same listener.
• drain in the open handler already sends a write parked while connecting. That write's 'connect' listener now skips a chunk drain took. Without the guard it goes out twice.
• TLSSocket._final leaves the no-handle case to net.Socket._final, which waits for 'connect' while connecting.
• Verified: 8 new tests in test/js/node/tls/node-tls-connect.test.ts (5 fail on main), one Windows test in node-tls-namedpipes.test.ts. Self-reviewed: 4 concerns raised, 4 addressed. Suites and exclusions are in the notes.

Background

• tls.connect({ socket }) wraps an existing stream. For a connected TCP socket, Bun moves the fd into a native TLS socket (upgradeTLSDeferred) and the native open callback runs inside that call. Otherwise a TLS engine runs over the stream (upgradeDuplexToTLS) and open runs a tick later.
• While connecting is true, _write parks one chunk (_pendingData). _write, _final, _read, ref() and unref() wait on once('connect').
• A direct tls.connect(port) emits 'connect' through afterConnect. SocketHandlers2.open skips that for a wrapped socket and calls drain, which sends the parked write.

Notes

Repro (from the report), raw still connecting when it is wrapped:

const raw = net.connect(port, "127.0.0.1");
const c = tls.connect({ socket: raw, rejectUnauthorized: false });
c.once("connect", () => c.write("first;"));
c.once("secureConnect", () => { c.write("second;"); c.end(); });

	client events	server received
node v26.3.0	connect, secureConnect, write callbacks, finish, close	first;second;
bun 1.4.3, main	secureConnect, second write callback, finish, close	second;
this branch	same as node	first;second;

What matches node, and where. Event matrix for the fd branch (upgradeTLSDeferred), {wrapped while connecting, wrapped after connect, direct} x first action at {same tick, TLSSocket 'connect', wrapped socket's 'connect'} x {write, write+end, end}, against a TLS server that ends when the client does. Before: the three "TLSSocket 'connect'" cells of a socket wrapped while connecting do nothing, and "same tick, end" emits 'finish' and then hangs. After: every cell gives node's event list, except that a bare end() before the handshake gives no 'secureConnect'. That difference is the same for a direct tls.connect(port) and is described in #42181. The eight new tests were also run as a plain script on node v26.3.0 and hold there.

Each added clause has a test that fails without it (checked by deleting the clause): the emit in the wait branch (tests 1, 2), the listener in the stream branch ("a preamble written before the wrap"), self.connecting = false ("a socket wrapped before it dials", where open has not run yet), a deferred emit such as process.nextTick (test 1 pins that the event runs inside the wrapped socket's own emit), the _pendingData guard (test 2 receives before connect;before connect;from connect; without it), the _final change (the end() test), self.destroyed and connection instanceof Socket (the last two tests). The self[kupgraded] !== connection half of the guard mirrors onUpgradedClose from #39066. It is reachable by calling connect({ socket }) again on the same TLSSocket before the first socket connects, and has no test, as in #39066.

Windows. Run on a Windows x64 debug build: tls.connect({ socket: net.connect(pipeName) }) emitted no 'connect' before and does now (the new test in node-tls-namedpipes.test.ts fails without the change and passes with it). node-tls-connect.test.ts, node-tls-upgrade.test.ts and node-tls-socket-allow-half-open-option.test.ts pass there. should work with named pipes and tls times out in a debug build with and without the change.

Not node's behaviour after this change, all of it also true on main:

• The end() claim ("sends the FIN") holds for the fd branch only. In the stream branch (parked write, named pipe) an end() before the connect now gives 'connect', 'finish', and the peer still sees no FIN. main gives nothing at all there. The engine does not end the underlying stream when it is shut down before the handshake. It reproduces on main with a plain Duplex transport and is reported separately.
• end() before a wrapped connect that is then refused: main emits a spurious 'finish', this branch emits nothing (node: 'error', 'close'). Neither emits 'error' or 'close' until node:tls: report a wrapped socket's connect failure on the TLSSocket #38122 lands.
• A zero-length write parked before the connect (write(""), end("")): its callback runs from drain inside the native open, before 'connect' and before the handle is assigned, so end("") still finishes with no FIN. node keeps that write pending until the handshake completes. Same root as the next item.
• Excluded on purpose from the _final change: new tls.TLSSocket(raw, { isServer: true }).end() in the wrap tick (named as out of scope in tls: end() and destroySoon() before the handshake completes now send the FIN #42181). It needs a wait on the handle attach (kUpgradeAttached), not on 'connect'. node:tls: send the FIN when end() runs before the TLS handle is attached #42339 adds that wait.
• On Windows, end() in the same tick as wrapping an already connected named pipe never emits 'finish': the TLSSocket reports connecting for one tick and nothing emits 'connect' for it. Unchanged here, reported separately.

One behaviour change outside tls. The _pendingData guard sits in the shared _write. A plain net.Socket that is reused after a failed connect() with a parked write keeps the stale 'connect' listener of that write. node, bun 1.4.3 and main then send the stale chunk again on the next connect and emit ERR_MULTIPLE_CALLBACK. With the guard the stale listener does nothing and only the current write goes out. Plain net.connect and direct tls.connect dials with a parked write are unchanged.

Effect outside tls. http.ClientRequest#setTimeout and _deferToConnect (setNoDelay, setSocketKeepAlive) wait for 'connect' on a connecting socket. With a createConnection that returns such a TLSSocket they never ran.

Adjacent open PRs, none of which emits the event: #38122 (the wrapped socket's connect failure, same callback), #42176, #36534. Two open PRs edit TLSSocket.prototype._final too and will need a textual merge with this one. #42330 covers a new TLSSocket(stream) wrap that was never connected. #42339 (opened while this was in review) makes _final wait for the handle attach, which fixes the same end() symptom from the other side and also the server-side wrap. It emits no 'connect'. Both changes send the no-handle case to net.Socket._final, so they compose: with both, _final waits for the attach and then finds connecting already false.

Suites run with the change (Linux debug build): test/js/node/tls/, test/js/node/net/, test/js/node/http2/, test/js/bun/net/, and the vendored test-tls-*, test-https-*, test-net-*, test-http2-* files. Local failures that are the same with and without this change: SNICallback runs even when the requested servername matches the bind hostname, socket > should not call drain before handshake, net.Socket read > ... in node-net.test.ts, and the vendored test-https-timeout.js.

---

no test proof · iteration 0 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/node/tls/node-tls-namedpipes.test.ts

[robobun]

^{Updated 9:50 AM PT - Sep 11th, 2026}

✅ @robobun, your commit 5d81c67da813e19e860738d10669ee664e98a9da passed in Build #114336! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 42340

That installs a local version of the PR into your bun-42340 executable, so you can run:

bun-42340 --bun

[robobun]

Status

Reproduced with the script from the report (raw = net.connect(port) wrapped by tls.connect({ socket: raw }) before it connects, first write issued from the TLSSocket's 'connect' listener):

• node v26.3.0: connect, secureConnect, both write callbacks, finish, close. Server receives first;second;.
• bun 1.4.3 and main: no connect. Server receives second;.
• this branch: same as node.

To check locally:

bun bd test test/js/node/tls/node-tls-connect.test.ts -t "still connecting"

8 tests. 5 fail on main, 3 pin the cases where no 'connect' is due. The Windows named pipe case is test/js/node/tls/node-tls-namedpipes.test.ts, run on a Windows x64 debug build: it fails without the change and passes with it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Essentials

Run ID: 82abf4b9-071e-43c1-b10a-e22023c0e9b5

📥 Commits

Reviewing files that changed from the base of the PR and between 6a92015 and 5d81c67.

📒 Files selected for processing (4)

• src/js/node/net.ts
• src/js/node/tls.ts
• test/js/node/tls/node-tls-connect.test.ts
• test/js/node/tls/node-tls-namedpipes.test.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 2 remain after this review.

---

Walkthrough

TLS upgrades over connecting sockets now emit connect after the underlying connection completes. Pending writes avoid duplication, finalization handles handle-less sockets, and tests cover event ordering, writes, FIN behavior, destruction, custom Duplex transports, and named pipes.

Changes

TLS upgrade connection handling

Layer / File(s)	Summary
Complete upgraded socket connections src/js/node/net.ts	Connecting sockets now re-emit connect after the underlying connection completes. Deferred upgrades use the same handler, and pending writes are not duplicated.
Finalize wrapped TLS sockets src/js/node/tls.ts	TLSSocket._final waits for the handshake only when the required handle, connection, and pending-write conditions exist.
Validate wrapped-socket behavior test/js/node/tls/node-tls-connect.test.ts, test/js/node/tls/node-tls-namedpipes.test.ts	Tests cover event ordering, write delivery, stream preambles, deferred FIN, destruction, custom Duplex transports, and named pipes.

Suggested reviewers: cirospaciari

Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to 5d81c

No actionable merge-blocking risk remains in the reviewed TLS connection changes.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: emitting 'connect' on a TLSSocket that wraps a connecting socket.
Description check	✅ Passed	The description clearly explains the problem, implementation, scope, verification results, and known limitations. It does not use the exact template headings, but it provides the required information …

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

I reviewed this PR and didn't find any bugs. Because it changes shared Socket.prototype._write behavior for all net.Socket instances and reworks TLSSocket._final in a way that interacts with two other open PRs on the same method, a human look at those cross-cutting effects would still be worthwhile.

What was reviewed:

• onUpgradedConnect placement on both the immediate-duplex-upgrade and deferred-'connect' paths — both set this[kupgraded] and this._handle before the emit, so listeners see consistent state.
• The _pendingData !== chunk guard against the drain call in the open handler — the closure-captured chunk identity check correctly short-circuits only the already-flushed write, and the PR notes the intentional side-effect on stale parked writes after a failed reconnect.
• TLSSocket._final no-handle fallthrough — NetSocket.prototype._final handles the connecting wait, so end() before connect no longer finishes early.
• Tests: port: 0/127.0.0.1, Promise.withResolvers, await using, no sleeps, error events wired to reject, negative cases (already-connected, destroyed-before-connect, plain Duplex) all covered.

Extended reasoning...

Overview

The PR makes tls.connect({ socket }) re-emit the wrapped net.Socket's 'connect' event on the resulting TLSSocket, matching Node's internal/tls/wrap.js behavior. It touches src/js/node/net.ts (new onUpgradedConnect helper wired into two upgrade branches, plus a _pendingData !== chunk guard in the shared Socket.prototype._write) and src/js/node/tls.ts (TLSSocket.prototype._final now falls through to the base _final when _handle is absent instead of returning early). ~246 lines of tests are added to node-tls-connect.test.ts covering event ordering, pre-connect write delivery, TLS-over-stream paths, and end() before connect; a Windows named-pipe test is added to node-tls-namedpipes.test.ts.

Security risks

None identified. The change is purely event-ordering and lifecycle plumbing on the client side of a TLS wrap; it does not touch certificate validation, rejectUnauthorized handling, TLS options merging, or any credential path. The instanceof Socket check gates on a module-local class (not a user-overridable global), matching the existing pattern.

Level of scrutiny

High. src/js/node/net.ts and src/js/node/tls.ts are hot-path Node-compat modules where event ordering and state-flag values relative to emits are load-bearing for the ecosystem. The _pendingData !== chunk guard sits in the shared _write used by every net.Socket, and the PR description explicitly documents a behavior change outside TLS (a stale parked write on a reused socket after a failed connect no longer double-sends / no longer emits ERR_MULTIPLE_CALLBACK). The _final change is also noted to require a textual merge with two other open PRs (#42330, #42339) that edit the same method. These are exactly the interactions a maintainer should sign off on.

Other factors

The implementation follows local conventions closely: onUpgradedConnect mirrors the neighboring onUpgradedClose (named function, .bind(null, self, connection), self[kupgraded] !== connection guard), the Node source permalink is cited at the definition, and the deferred-branch call runs after _handle assignment so pending reads false in the listener as asserted. Tests follow harness conventions (combined-object .toEqual, await using disposal, error events wired to reject the awaited promise, no timing waits) and include negative-contract cases. The PR description is unusually thorough — it names which added clauses each test proves live, enumerates remaining non-Node behaviors, and cross-references adjacent open PRs — which itself argues for a human confirming those stated interactions rather than an automated approval.

[Jarred-Sumner]

Superseded by #44618, which consolidates the open TLS pull requests. This fix and its tests are in there, either as written, rewritten smaller, or merged with the other PRs that patched the same cause (see the "By area" list in that PR). Closing in favor of it.