Http server #ap6

I’m stuck on Stage #AP6.

I’ve tried everything gpt asked friend but not able to get where i am wrong

Here are my logs:

remote: [tester::#AP6] >
remote: [tester::#AP6] Sent bytes: “GET /files/non-existentblueberry_blueberry_raspberry_raspberry HTTP/1.1\r\nHost: localhost:4221\r\n\r\n”
remote: [tester::#AP6] Failed to read response:
remote: [tester::#AP6] Received: “” (no content received)
remote: [tester::#AP6] ^ error
remote: [tester::#AP6] Error: Expected: HTTP-version, Received: “”
remote: [tester::#AP6] Test failed
remote: [tester::#AP6] Terminating program
remote: [tester::#AP6] Program terminated successfully

And here’s a snippet of my code:

          else if (url.includes('/files/') && method === "GET") {
            const directory = process.argv[3];
            const filename = url.split("/files/")[1];
            const filePath = `../${directory}/${filename}`;
            if (fs.existsSync(filePath)) {
                // Respond with the file content
                const content = fs.readFileSync(filePath).toString();
                const res = `HTTP/1.1 200 OK\r\nContent-Type: application/octet-stream\r\nContent-Length: ${Buffer.byteLength(content)}\r\n\r\n${content}`;
            } else {
                // Respond with 404 Not Found
                const res = 'HTTP/1.1 404 Not Found\r\nContent-Length: 0\r\n\r\n';

I think there is some problem in the testing system. Today the exact same code passed all the test.

I see that the submission that passed was indeed marked as flaky (we haven’t exposed this in the UI yet, but it’s visible to staff internally):

Flakiness is most often caused by a concurrency-related bug, but can also cause due to errors with how CodeCrafters tests/executes your code. We haven’t seen flakiness w/ Javascript submissions on this stage a lot, so I’ll get a team member to take a closer look at this and report back!

Hey @Msimbaji,

We were able to identify the issue here. Our starter code contained this block:

   socket.on("close", () => {
     server.close(); // This is the problem!

This shuts the server down when a connection is closed. This was the first stage where this flow was being triggered, hence the error. We’ve fixed this in the starter code now: Refactor server code and remove unnecessary server.close() calls by rohitpaulk · Pull Request #74 · codecrafters-io/build-your-own-http-server · GitHub.

We’re also changing the tests for the “Concurrent Connections” stage to test this behaviour earlier, instead of waiting till the get/post file stages.

Thank you for highlighting this!

Happy to help community. Will i get a certificate for finding bug though :clown_face:?

1 Like

Since you asked…

Nah :saluting_face: my interviewer will be happy seeing it in my resume