carlos / platform Public

While running the full go test ./... -count=1 gate on a fresh checkout cut from main (branch feature/instance-db-stats-card, unrelated to this bug — the branch only touches internal/console's app Overview page), I hit two unrelated failures:

• internal/tunnelclient.TestDialAndServeInvertsConnection hangs past the 600s test timeout (both inside the sandbox's default network restrictions and with them explicitly disabled). It spins up a local httptest.Server and an HTTP/2 connection over a hijacked raw TCP conn — nothing that should need outbound network.
• internal/edge's fleet/tunnel e2e suite (TestFleetRouteProxiesToBoundBox, TestFleetRouteFallsOverWhenBoundBoxIsDark, TestFleetRouteWithNoBoundBoxUsesFallback, TestExplicitTunnelPrecedesFleetPlacement, TestTunnelEndToEnd, TestDynamicChannelMarkedDynamic, TestTwoBoxFleetEndToEnd, TestFleetBoxConvergesWithoutBucketCredentials) all fail after ~5s with "tunnel lost — re-dialing" / "tunnel retry in ...s" in their fake-box logs.

Every other package (21+ others, including internal/console, internal/host, internal/status, internal/metrics) passed cleanly in the same run. Both failing areas are the tunnel/relay subsystem specifically, which smells like this particular sandbox lacking some networking primitive those tests rely on (UDP, loopback behavior, timing) rather than a real regression — but I haven't dug further since it's unrelated to the branch I was on. Flagging per "a known-failing test is a defect in its own right" (AGENTS.md) in case it's hiding something real, or in case it's simply a sandbox limitation worth a documented workaround (env var, build tag, skip condition) for agents running the full suite in similar sandboxes.