Repository navigation
Conversation
Benchmark handleInvoke end to end (session lookup, preflight dial, JWT signing, reverse proxy) against an in-process upstream, for the SandboxClaim kind that signs a JWT and the CodeInterpreter kind that does not. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: manaspros <manasnandchoudhary@gmail.com>
waitForUpstreamReachable opened and closed a TCP connection to the sandbox on every request, then the proxy connected again. cmd/router never sets InitialConnectRetryCount, so the preflight had a single attempt and could not wait for anything. Return early when the retry count is 0 and give the proxy transport the same dial timeout the preflight used, so an unreachable sandbox still fails after 200ms. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: manaspros <manasnandchoudhary@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #490 +/- ##
==========================================
+ Coverage 60.45% 61.46% +1.00%
==========================================
Files 35 35
Lines 3616 3643 +27
==========================================
+ Hits 2186 2239 +53
+ Misses 1211 1184 -27
- Partials 219 220 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| // Without retries the preflight is one more connect to the sandbox that | ||
| // the proxy repeats right after. The proxy transport has the same dial | ||
| // timeout (see NewServer), so it reports the same errors. | ||
| if retryCount == 0 { |
There was a problem hiding this comment.
InitialConnectRetryCount is not exposed as a Router CLI flag, so deployed routers always use the default value of 0. Should we expose it as a flag if we intend to retain the retry path?
There was a problem hiding this comment.
Also, InitialConnectRetryCount suggests the number of retries after an initial connection attempt. Using 0 to skip the initial attempt seems inconsistent with that meaning. WDYT?
What type of PR is this?
/kind enhancement
What this PR does / why we need it:
waitForUpstreamReachabledials the sandbox, closes the connection, and then the proxy connects again.cmd/routerdoes not setInitialConnectRetryCount, so it is 0 in the real binary and the preflight has one attempt, which the proxy repeats anyway.This PR:
waitForUpstreamReachableearly whenInitialConnectRetryCountis 0;http.TransportaDialContextwithTimeout: config.InitialConnectRetryInterval(200 ms by default). That is the dial timeout the preflight used, so an unreachable sandbox still fails after 200 ms and not after the OS connect timeout.With retries configured (> 0) nothing changes.
The error a client sees is the same. I checked:
upstreamUnavailableResponsemaps both the preflight error and the proxy error, and a refused connection still returns 502. I added a test for that. The test also passes on main, which is the point.Two commits, benchmark first. The benchmark is the same file as in the JWT PR (identical content), so whichever merges first, the other should rebase cleanly.
CodeInterpreterdoes not sign a JWT, so it shows the preflight saving alone: 48.10µ to 29.35µ, allocs 194 to 151.SandboxClaimis dominated by JWT signing (see my other PR), so the same saving is only 4.53 percent there. The upstream is on loopback, so in a cluster the saving per request is larger by one round trip.Which issue(s) this PR fixes:
Fixes #489
Special notes for your reviewer:
What I did not test: a real cluster, a blackholed pod IP (the 200 ms dial timeout on the transport is there for this, I tested only the refused case), and a router started with retries configured. The existing
TestWaitForUpstreamReachable_RetriesUntilReadycovers the retry path and still passes.I am not sure about one thing and would like a maintainer view. After this change a router that has no retries relies on the proxy for the first connect. #256 was about a race right after sandbox creation. The workload manager already probes the entrypoints before it returns the sandbox (
waitForSandboxEntryPointsReady), and the retry knob is still there for anyone who sets it. If you want the preflight kept for newly created sessions, that is an easy change.New tests: preflight does not accept a connection with 0 retries, and a refused upstream still returns 502 through the router.
go test -race ./pkg/...passes. Lint: golangci-lint v2.15 with an equivalent config (the Makefile pins v1.64.1 but the config is v2), no new findings in non-test code.AI use: I used Claude Code to find this and to draft the code, benchmark and tests. I read and ran all of it and I can explain each line.
Does this PR introduce a user-facing change?: