branderson
06018fdda4
tests / confined (mirror) (pull_request_target) Successful in 1m17s
tests / confined (conversation) (pull_request_target) Successful in 1m18s
tests / confined (proxy) (pull_request_target) Successful in 1m30s
tests / confined (providers) (pull_request_target) Successful in 2m13s
tests / confined (launch) (pull_request_target) Successful in 2m37s
tests / confined (share) (pull_request_target) Successful in 2m25s
tests / runner-env (confined) (pull_request_target) Successful in 1m11s
tests / confined (shellcheck) (pull_request_target) Successful in 1m41s
tests / confined (remote) (pull_request_target) Successful in 3m12s
tests / confined (audit) (pull_request_target) Successful in 4m12s
tests / confined (project) (pull_request_target) Successful in 4m52s
tests / confined (static) (pull_request_target) Successful in 4m1s
tests / confined (config) (pull_request_target) Successful in 5m57s
tests / privileged (pull_request_target) Successful in 6m17s
tests / runner-env (privileged) (pull_request_target) Successful in 1m4s
BaseHTTPRequestHandler answers 100 Continue and returns True before do_* runs, so the proxy invited the upload, read the declared length in _read_body, refused it and closed mid-flight. Whether the client read the 413 or only the 100 was timing - a race the client cannot win and a test cannot pass reliably, which is how it was found: an intermittently red proxy job on a pull request that did not touch the proxy. The cap itself was doing the thing that matters, in that nothing oversized was read into host memory. What was wrong was the conversation. The new test asks what the FIRST answer is and sends no body at all, which is the question the race cannot reach: the one beside it passes either way when the timing is kind. Fixes #400