Summary

agent-base's createSocket() uses socket instanceof http.Agent to determine whether the return value of connect() is an agent (call addRequest()) or a raw socket. This is stricter than Node.js core, which uses duck typing (typeof agent.addRequest === 'function' in _http_client.js).

This causes agents that implement addRequest() but don't inherit from http.Agent to be misidentified as raw sockets, causing HTTP requests to hang indefinitely without any error.

The fix adds a duck typing fallback:

// Before:
if (socket instanceof http.Agent) {

// After:
if (socket instanceof http.Agent || (typeof socket.addRequest === 'function')) {

Background: how this bug was discovered

While using the vs-picgo VSCode extension to upload images to GitHub, every upload would hang for exactly 30 seconds before succeeding on retry.

Root cause chain:

1. vs-picgo uses the request library with tunnel-agent for HTTPS-over-HTTP proxy tunneling
2. tunnel-agent's TunnelingAgent inherits from EventEmitter, not http.Agent — this is valid since Node.js core only requires duck typing for options.agent
3. VSCode's @vscode/proxy-agent patches https.request() and intercepts the request (for system certificate injection, addCertificatesV1=true)
4. The proxy resolver returns DIRECT, so PacProxyAgent.connect() returns the original TunnelingAgent as-is
5. agent-base's createSocket() checks TunnelingAgent instanceof http.Agent → false
6. The TunnelingAgent is stored as currentSocket, then returned via createConnection() to Node's HTTP client as if it were a raw TCP socket

Exact hang mechanism (from Node.js _http_outgoing.js _deferToConnect):

// Node's _deferToConnect:
const onSocket = () => {
    if (this.socket.writable) {       // TunnelingAgent.writable = undefined → falsy
        callSocketMethod();            // ← never reached
    } else {
        this.socket.once('connect', callSocketMethod);  // ← waits forever
    }
};

Since TunnelingAgent.writable is undefined (falsy), Node thinks the "socket" isn't connected yet and waits for a 'connect' event. But TunnelingAgent is an EventEmitter that never emits 'connect', so the request hangs indefinitely — no error, no timeout, no output. PicGo's 30-second REQUEST_TIMEOUT_MS eventually fires, and the retry with proxy: null uses https.globalAgent (a real http.Agent), which succeeds.

Reproduction:

const http = require('http');
const EventEmitter = require('events');
function TunnelingAgent() { EventEmitter.call(this); }
require('util').inherits(TunnelingAgent, EventEmitter);
TunnelingAgent.prototype.addRequest = function() { /* ... */ };

const agent = new TunnelingAgent();
const req = http.request({ host: 'example.com' });
req.onSocket(agent);  // hangs forever — no error, headersSent stays false

Why this should be fixed in agent-base

• Node.js core (_http_client.js) uses duck typing for options.agent — only checks typeof agent.addRequest === 'function'
• tunnel-agent (billions of downloads, used by request library) relies on this duck typing contract
• agent-base is the layer that introduces the stricter instanceof check, creating an incompatibility with legitimate duck-typed agents
• Any agent-base subclass (e.g. PacProxyAgent, HttpsProxyAgent, SocksProxyAgent) that returns a duck-typed agent from connect() will trigger this bug

Trigger conditions

This bug is triggered when all of the following conditions are met:

1. An agent-base subclass's connect() method returns an object that:
   • Has an addRequest() method (duck-typed agent)
   • Does NOT inherit from http.Agent (fails instanceof check)
2. In the VSCode-specific case:
   • Extension uses a library with tunnel-agent (e.g., request with proxy config)
   • VSCode's http.proxySupport is set to on (default)
   • @vscode/proxy-agent intercepts the request for certificate injection
   • Proxy resolver returns DIRECT, passing the original TunnelingAgent through

Test plan

• Extensions using tunnel-agent (e.g. vs-picgo) no longer hang when proxy resolver returns DIRECT
• Standard http.Agent instances still work correctly
• Raw sockets (Duplex streams without addRequest) still work correctly
• No regression in existing proxy-agent test suites