fix: filter IPC and Unix domain socket false positives from TCP instrumentation

[sohankshirsagar]

Summary

The TCP instrumentation's unpatched dependency detection was firing false positives for Node.js IPC traffic — specifically process.send() calls made by tools like tsx (TypeScript compiler) and test runners (Jest workers, etc.). These IPC writes go through net.Socket.write but are purely local parent-child process communication, not external network calls.

The fix distinguishes inherited IPC pipes from real connections by tracking which sockets go through connect(). IPC pipes are inherited from the parent process and never call connect(), while Unix domain socket connections (e.g. PostgreSQL via a socket file) do — so we only filter Pipe sockets that were never explicitly connected.

Changes

• Replaced _isHttpResponseSocket() with a broader _isNonNetworkSocket() method that consolidates all non-network socket filtering
• Added a WeakSet (explicitlyConnectedSockets) that tracks sockets passing through the patched connect() call
• In _isNonNetworkSocket, Pipe-handle sockets are only filtered if they were never connected — this filters inherited IPC pipes (tsx, jest workers, process.send()) while still alerting on Unix domain socket connections that could be unpatched dependencies
• Existing HTTP response socket filtering (_httpMessage check) is preserved within the new method

Context

The false positive manifested as Unpatched dependency alert log spam during replay runs. The stack trace showed tsx's sendToParent → process.send() → Socket.write, which the SDK intercepted and misidentified as an uninstrumented external call. IPC sockets never leave the machine and are irrelevant to record/replay.

Both IPC pipes and Unix domain sockets use Pipe handles internally (source), so a blanket Pipe check would hide unpatched dependencies connecting over Unix domain sockets. The connect()-tracking approach avoids this: inherited IPC pipes never call connect(), real connections always do.

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/instrumentation/libraries/tcp/Instrumentation.ts">

<violation number="1" location="src/instrumentation/libraries/tcp/Instrumentation.ts:203">
P1: Treating every `Pipe` handle as non-network hides unpatched dependencies that connect over Unix domain sockets.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[tusk-dev]

Generated 19 tests - 19 passed

 

Tip

New to Tusk Unit Tests? Learn more here.

Test Summary

• _handleTcpCall - 5 ✓
• _isNonNetworkSocket - 10 ✓
• _patchNetModule - 3 ✓
• connect - 1 ✓

Results

Tusk's tests all pass and validate the core fix: the new _isNonNetworkSocket() method correctly filters out IPC and Unix domain sockets while preserving HTTP response socket filtering. The 10 tests for _isNonNetworkSocket cover the critical path—detecting Pipe handles for IPC traffic (like tsx and Jest workers), distinguishing between inherited IPC pipes and explicitly connected Unix sockets, and ensuring TCP sockets still get instrumented. The _handleTcpCall tests confirm the integration works end-to-end: non-network sockets bypass instrumentation, and unpatched dependency logging only fires for SERVER spans without ProtobufCommunicator. The connect and _patchNetModule tests verify socket tracking and mode-aware patching work as expected. This eliminates the false positive spam from IPC writes while keeping real network instrumentation intact.

View check history

Commit	Status	Output	Created (UTC)
29ee546	Generated 18 tests - 18 passed	Tests	Mar 17, 2026 6:07PM
cd4cd7b	Generated 19 tests - 19 passed	Tests	Mar 17, 2026 6:39PM

Was Tusk helpful? Give feedback by reacting with 👍 or 👎

[jy-tan]

is there possibility where a unix domain socket was already connected before Socket.prototype.write() is patched? then the heuristic might miss this case.

[sohankshirsagar]

is there possibility where a unix domain socket was already connected before Socket.prototype.write() is patched? then the heuristic might miss this case.

as long as TuskDrift.initialize() runs before any other imports, this shouldn't happen. first time anything does require('net') the hook will fire and patch Socket.prototype.connect and Socket.prototype.write