Repository navigation
Conversation
…ady answers withManagedServer spawned the SDK's server and then polled its url until something answered. A leftover process on that port answered first, so the run graded the leftover. The new server usually died on bind and ended the run partway through with "Server exited with code 1". A command that does not exit on a failed bind graded the stranger to the end. Probe the url once before spawning, and refuse with a message that names the url when anything answers.
commit: |
JosephDoUrden
left a comment
JosephDoUrden
left a comment
There was a problem hiding this comment.
Ran npx vitest run src/sdk-runner/managed-server.test.ts: 2/2 pass. With index.ts from main, the held-port test fails as described. I also put a leftover on ::1 and on 127.0.0.1 against localhost urls, and all 6 combinations were refused.
One gap: answers() (index.ts:44) treats a timeout as a free port. A leftover that accepts the connection but stalls past 1s gets through, and the run ends with the old Server exited with code 1 after about 1s. Treating only ECONNREFUSED as free would cover it.
Looks good to me otherwise.
A leftover that accepts the connection and then stalls made the probe time out. The old check read a timeout as a free port, so the run went ahead and later failed with "Server exited with code 1". The probe now counts the port as free only on ECONNREFUSED and the other nobody-listening codes. A localhost url reports one error for ::1 and one for 127.0.0.1, and both must say nobody is listening. The error message now says why the port looks held.
panyam
changed the title
|
Thanks, good catch. I reproduced it with a leftover that accepts the socket and never answers. The run ended with Fixed in 88c9ea8. The probe now counts the port as free only on ECONNREFUSED (plus EADDRNOTAVAIL, ENETUNREACH and EHOSTUNREACH). A localhost url reports one error for ::1 and one for 127.0.0.1, and both must say nobody is listening. A timeout or a reset counts as held, and the error now says which one it was. I added a test for the stalled leftover. It fails on the first commit with the old |
I hit this in my own conformance runs. A leftover server from an earlier run still held the fixture's port. The new server failed to bind, and the suite came back green against the old one.
sdk --mode servercan do the same thing.withManagedServerspawns the server, then polls the url until anything answers. A leftover process answers first.EADDRINUSE, and the run ends partway through withServer exited with code 1 before tests completed. The error doesn't mention the port.The fix probes the url once before spawning. It counts the port as free only when the connect is refused. If something answers, or accepts the connection and then stalls, the runner refuses with an error. The error names the url and says why the port looks held.
Tests in
src/sdk-runner/managed-server.test.ts:mainthis test fails withpromise resolved "undefined" instead of rejecting, so the run went ahead against the leftover.Server exited with code 1after about 1s.Related to #114, which wants the runner to own server lifecycle for all SDKs.