Problem
All E2E inference goes through the DNS-rewritten NVIDIA Endpoints path. Custom OpenAI-compatible endpoints (deepinfra, together.ai, etc.) use the FORWARD-mode proxy branch in nemoclaw-blueprint/scripts/http-proxy-fix.js, which is never exercised in E2E.
Bug 3 of the weekend regression (#2490) — forward-proxy fields leaking into https.request — was only discovered by a community user (mflova) on Discord after upgrading from 0.0.23 to 0.0.24. No existing or planned E2E test would have caught it.
PR #2490 added unit-level bisect-proof tests (http-proxy-fix-rewrite.test.ts, http-proxy-fix-e2e.test.ts) that pin every stripped field. But the full sandbox → gateway → proxy → upstream path through FORWARD-mode is not exercised.
Proposal
Add a forward-proxy-e2e nightly job that:
- Onboards with a custom
compatible-endpoint provider pointing to a local mock HTTPS server (or a known free endpoint)
- Sends a chat completion request through the sandbox
- Verifies the request reaches the upstream without forward-proxy field contamination
- Verifies the response returns through the proxy without corruption
The mock server approach is simplest: spin up a tiny Node HTTPS server on the host that echoes back headers, configure NEMOCLAW_COMPATIBLE_ENDPOINT_URL to point at it, and assert the request headers do not contain Proxy-Authorization, agent, socketPath, or other hop-by-hop fields.
What This Would Have Caught
Context
Problem
All E2E inference goes through the DNS-rewritten NVIDIA Endpoints path. Custom OpenAI-compatible endpoints (deepinfra, together.ai, etc.) use the FORWARD-mode proxy branch in
nemoclaw-blueprint/scripts/http-proxy-fix.js, which is never exercised in E2E.Bug 3 of the weekend regression (#2490) — forward-proxy fields leaking into
https.request— was only discovered by a community user (mflova) on Discord after upgrading from 0.0.23 to 0.0.24. No existing or planned E2E test would have caught it.PR #2490 added unit-level bisect-proof tests (
http-proxy-fix-rewrite.test.ts,http-proxy-fix-e2e.test.ts) that pin every stripped field. But the full sandbox → gateway → proxy → upstream path through FORWARD-mode is not exercised.Proposal
Add a
forward-proxy-e2enightly job that:compatible-endpointprovider pointing to a local mock HTTPS server (or a known free endpoint)The mock server approach is simplest: spin up a tiny Node HTTPS server on the host that echoes back headers, configure
NEMOCLAW_COMPATIBLE_ENDPOINT_URLto point at it, and assert the request headers do not containProxy-Authorization,agent,socketPath, or other hop-by-hop fields.What This Would Have Caught
http.request→https.requestrewrite dragged forward-proxy hop fields →TypeError: Protocol "https:" not supportedon custom endpointsContext
test/http-proxy-fix-rewrite.test.ts,test/http-proxy-fix-e2e.test.ts