Skip to content

step 4: run both arms with egress blocked; a test that names a host has left the machine #20

Description

@lenamonj

Step 4 proves the test red on the base and green with the patch. Nothing in that step, or in housebroken branch, runs the red arm with egress blocked, so a test whose red arm reaches the network passes the gate.

On teslamotors/vehicle-command #479 the filed test posted an oversized body to a route the proxy does not have, fell through to the pass-through forwarder, and on the base (where nothing bounded the body) sent a real POST carrying a forged bearer token to fleet-api.prd.na.vn.cloud.tesla.com. It was the only test in the file that could reach the forwarder without stubbing the upstream client. The adversarial review of a later rework found it by re-running the red arm with HTTPS_PROXY=http://198.51.100.1:9: the failure message then named the host.

Proposed check, in step 4 and in housebroken branch:

  1. Run the red arm and the green arm with HTTP_PROXY, HTTPS_PROXY, ALL_PROXY set to a black-hole address and NO_PROXY empty (or the language's equivalent: GOFLAGS=-mod=mod does not matter, GOPROXY=off for module fetches).
  2. Fail the gate when either arm's output names a host, a URL, dial tcp, proxyconnect, EOF from a proxy, or the black-hole address itself.
  3. Print the failing test name and the line of output that named the host.

A test that fails this check is rewritten to stub the client the way its neighbouring tests do; it is never fixed by allowing the network.

Lesson row: docs/lessons.md, 2026-09-16, teslamotors/vehicle-command #479.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions