[Bug Report]: Perry Built-in HTTP Client Cannot Establish Network Connections on macOS arm64

[FullStackPlayer]

Summary

Perry's built-in HTTP client modules (fetch, axios, node:http, net) are unable to establish any network connections — including to localhost and direct IP addresses — when compiled to a native binary on macOS arm64. The child_process module works correctly, and external tools like curl can make network requests without issues, confirming the host machine has full network connectivity.

Environment

Item	Value
Perry Version	0.5.891 (also tested: 0.5.511, 0.5.890 — same result)
OS	macOS 26.4.1 (Darwin)
Architecture	arm64 (Apple Silicon)
Perry Package	@perryts/perry-darwin-arm64 0.5.891
Xcode CLI Tools	Installed
Network	Fully functional (verified via system curl)

Steps to Reproduce

Case 1: fetch fails

// fetch_test.ts
const response = await fetch("https://api.ipify.org?format=json");
console.log(response.status);

perry compile fetch_test.ts -o fetch_test && ./fetch_test
# Expected: 200
# Actual: Fetch error: error sending request for url (https://api.ipify.org/?format=json)

Case 2: axios fails

// axios_test.ts
import axios from "axios"
const res = await axios.get("https://api.ipify.org?format=json");
console.log(res.status);

perry compile axios_test.ts -o axios_test && ./axios_test
# Expected: 200
# Actual: Request failed: error sending request for url (https://api.ipify.org/?format=json)

Case 3: node:http client returns undefined

// http_test.ts
import { request } from "node:http"
const req = request("http://1.1.1.1/", (res) => { console.log(res.statusCode); });
req.on("error", (err) => { console.error(err); });
req.end();

perry compile http_test.ts -o http_test && ./http_test
# Expected: 200
# Actual: TypeError: Cannot read properties of undefined (reading 'on')

Case 4: net.connect fails

// net_test.ts
import * as net from "net"
const socket = net.connect({ host: "1.1.1.1", port: 80 }, () => { console.log("connected"); });
socket.on("error", (err) => { console.error(err.message); });

perry compile net_test.ts -o net_test && ./net_test
# Expected: "connected"
# Actual: TCP error: file name contained an unexpected NUL byte

Note: The error "file name contained an unexpected NUL byte" is a Rust CString::new() error, indicating that the hostname string passed to the underlying socket API contains NUL (\0) bytes. This strongly suggests a string handling bug in Perry's net module FFI bridge, where TypeScript strings are not properly converted to C-style strings before being passed to system calls.

Case 5: Direct IP and localhost also fail

await fetch("http://1.1.1.1/");       // → error sending request
await fetch("http://127.0.0.1:9999/"); // → error sending request

This rules out DNS resolution as the root cause.

Diagnostic Evidence

child_process + curl works correctly

import { execSync } from "child_process"
const result = execSync("curl -s https://api.ipify.org?format=json", { encoding: "utf8" });
console.log(result); // → {"ip":"x.x.x.x"} ✅

This confirms:

• The host machine has full network connectivity
• DNS resolution works at the OS level
• TLS/HTTPS works via system curl
• The compiled Perry binary can spawn child processes

Compilation output confirms stdlib is linked

Collecting modules...
Found 1 module(s): 1 native, 0 JavaScript    ← correctly detected as native
Generating code...
Linking (with stdlib)...                      ← stdlib linked (includes http-client)
Binary size: 7.2MB                            ← consistent with stdlib-included binary

Compare with runtime-only linking (no fetch):

Linking (runtime-only)...
Binary size: 1.1MB

perry dev mode also fails

The same fetch code fails identically when run via perry dev, ruling out a compile-only issue.

RUST_LOG=debug produces no additional output

No networking-related debug messages are emitted, suggesting the error occurs before any network I/O is attempted (possibly in the runtime initialization or FFI bridge).

perry --print-api-manifest confirms APIs are registered

child_process.spawn    ✅ listed
child_process.execSync ✅ listed
fs.readFileSync        ✅ listed
fs.statSync            ✅ listed

The HTTP client modules (fetch, axios, node:http, net) are also present in the manifest and linked.

Comparison with Known Issues

• Issue fetch().then() callbacks never fire in macOS native UI apps #6 (closed): fetch().then() callbacks never fire in macOS native UI apps — root cause was spawn() in fetch.rs not calling ensure_pump_registered(). This was fixed in a later version. Our issue is different: the connection itself fails, not just the callback resolution.

• Issue The "fetch" example does not seem to work as expected #26 (closed): Fetch example pulled in npm axios as JS module — our compilation correctly detects 1 native, 0 JavaScript, so this is not the same issue.

Workaround

Using child_process + curl as an HTTP transport proxy:

• Non-streaming: execSync("curl -s ...") — works synchronously
• Streaming: spawn("curl", ["-s", "-N", "-o", tmpFile, ...]) + file polling with setInterval + fs.readFileSync — works for SSE streaming

This workaround is functional but has drawbacks:

1. Requires curl to be available on the target system
2. Adds overhead from process spawning and file I/O
3. Streaming requires a temp file and polling (not event-driven)

Minimal Reproduction

// repro.ts — simplest possible reproduction
try {
  const res = await fetch("http://1.1.1.1/");
  console.log("OK:", res.status);
} catch (err: any) {
  console.error("FAIL:", err.message);
}

perry compile repro.ts -o repro && ./repro
# Output: FAIL: Fetch error: error sending request for url (http://1.1.1.1/)

Suggested Investigation Areas

1. String handling in FFI bridge: The net.connect error "file name contained an unexpected NUL byte" indicates TypeScript strings are not properly converted to C-style strings (CString) before being passed to socket APIs. This may also affect fetch/axios internally when resolving hostnames.
2. Tokio runtime initialization: Check if the async runtime is properly initialized for network I/O in CLI (non-UI) compiled binaries
3. Hyper/rustls client configuration: Verify the HTTP client backend (hyper + rustls) is correctly wired for outbound connections
4. Error propagation: The node:http request() returning undefined and net.connect previously returning "undefined" error both suggest the FFI error chain is broken — errors from Rust are not properly propagated to TypeScript

Environment Exclusion

The following external causes have been ruled out:

• macOS Firewall: Disabled (socketfilterfw --getglobalstate → State = 0)
• Binary sandbox/entitlements: Ad-hoc signed, no sandbox (codesign -dvvv → flags=0x20002(adhoc,linker-signed), no runtime flag)
• DNS issues: Direct IP connections also fail, ruling out DNS
• TLS issues: Plain HTTP connections also fail, ruling out TLS
• System network: child_process + curl works from the same binary, confirming host network is functional
• Version-specific regression: Tested across 3 versions (0.5.511, 0.5.890, 0.5.891) — all exhibit identical failures, confirming this is a systemic issue, not a regression

Cross-Version Test Results

Perry Version	Binary Size	fetch	axios	net.connect	node:http
0.5.511	5.4MB	FAIL	FAIL	FAIL (NUL byte)	FAIL (undefined)
0.5.890	7.3MB	FAIL	FAIL	FAIL (NUL byte)	FAIL (undefined)
0.5.891	7.3MB	FAIL	FAIL	FAIL (NUL byte)	FAIL (undefined)

All versions produce identical error messages, indicating the HTTP client stack has never worked on macOS arm64.

[TheHypnoo]

Hi @FullStackPlayer, thanks a lot for the detailed report — the cross-version table, the workaround notes, and especially the CString::new() hint were really helpful for narrowing this down.

I re-ran your repros on Perry v0.5.909 on a macOS arm64 machine (Darwin 25.2.0 / macOS 26.2, Apple Silicon). Here's what I see now:

Case	v0.5.909 on macOS arm64
fetch("http://1.1.1.1/")	✅ Works — 200 OK
axios.get("https://api.ipify.org?format=json")	✅ Works — 200 + correct JSON body
net.connect({ host, port }, cb) (options form)	❌ Still fails — "file name contained an unexpected NUL byte"
http.request("http://1.1.1.1/", cb)	❌ Still returns undefined

So fetch and axios look to have been fixed somewhere between 0.5.891 and 0.5.909. The other two are real and I've located the root causes:

• net.connect(options, cb) — the options-object overload isn't wired in codegen. The dispatch entry at crates/perry-codegen/src/lower_call.rs only accepts the positional net.connect(port, host) form. When you pass an options object, the object pointer gets reinterpreted as a number (port) and the callback gets reinterpreted as a string pointer — reading garbage bytes that happen to contain NULs, which then trips getaddrinfo's internal CString::new(). That matches your hint exactly — the NUL bytes weren't from your hostname string, they came from misinterpreting a function pointer as a string. As a separate issue, 'error' events are emitted as raw strings instead of Error objects, which is why err.message came back as undefined on some of your runs.
• http.request() — the runtime implementation (js_http_request) exists in crates/perry-stdlib/src/http.rs and is declared in the FFI table, but there's no NativeModSig { module: "http", method: "request", ... } entry in the codegen dispatch table. Only http.createServer is wired right now. So the call falls through to the unknown-method path and returns TAG_UNDEFINED, which is why req was undefined.

I've opened dedicated issues for the two remaining bugs and will start working on them:

• node:http request() returns undefined — missing codegen dispatch entry #769 — node:http request() returns undefined (missing codegen dispatch entry)
• net.connect(options, cb) options-object overload corrupts host string (NUL byte) #770 — net.connect(options, cb) options-object overload corrupts host string

Thanks again for the very thorough write-up — it saved a lot of triage time.

[TheHypnoo]

Hi @FullStackPlayer — quick update: both remaining issues split off from this report have now landed on main:

• node:http request() returns undefined — missing codegen dispatch entry #769 — node:http request() / get() client surface, fixed in fix: #769 — wire node:http / node:https client request through codegen dispatch #771: the dispatch entries were missing so the calls returned undefined; the runtime impl in perry-ext-http is now wired and the response-side property accessors (res.statusCode, res.statusMessage, res.headers) work too.
• net.connect(options, cb) options-object overload corrupts host string (NUL byte) #770 — net.connect({ host, port }, cb) options-object overload, fixed in fix: #770 — wire net.connect(options, cb) and emit Error objects #773: the options form connects correctly, the connectListener auto-fires on both overloads (options and positional), and 'error' events now ship Error-shaped objects so err.message works.

These will be in the next published Perry release. fetch and axios were already working in 0.5.909 (see the table further up the thread), so once the new version lands all four cases from your original repro should run as Node does.

Closing this one out — if anything related crops up on the new build, please open a fresh issue and we'll take it from there.

Thanks again for the very detailed report — the cross-version table and the CString::new() hint were genuinely useful while triaging.