Invalid access of discarded

[lewispham]

I'm having this error even with onAborted handled as instructed.

app.get("*", (res, req) => {
    try {
        const url = req.getUrl();
        console.log("SERVING URL", url);
        res.onAborted(() => {
            console.log(`Aborted request "${url}"`);
        });
        sendFile(res, url).catch(() => internalServerError(res));
    } catch (er) {
        internalServerError(res);
    }

});

internalServerError(res: HttpResponse) {
    res.cork(() => {
        res.writeStatus("500 Internal Server Error")
            .writeHeader("cache-control", "no-cache")
            .end("Internal Server Error");
    });
}

serveFile(res: HttpResponse, fileName: string, buf: Buffer) {
    res.cork(() => {
        if (fileName === "service-worker.js") {
            res.writeHeader("service-worker-allowed", "/");
        }
        res.writeHeader("cache-control", "no-cache")
            .writeHeader("content-type", mimeTypes.contentType(fileName) || "text/plain")
            .end(buf);
    });
}

async sendFile(res: HttpResponse, filePath: string) {
    try {
        const buf = await fs.readFile(filePath);
        serveFile(res, path.basename(filePath), buf);
    } catch (er: any) {
        console.log(er);
        if (er.code !== "ENOENT") {
            throw er;
        }
        notFound(res);
    }
}

notFound(res: HttpResponse) {
    res.cork(() => {
        res.writeStatus("404 Not Found")
            .writeHeader("cache-control", "no-cache")
            .end("URL Not Found");
    });
}
// Logs
SERVING URL /app/index.html
SERVING URL /app/index.html
SERVING URL /app/index.html
SERVING URL /app/index.html
Aborted request "/app/index.html"
Error: Invalid access of discarded (invalid, deleted) uWS.HttpResponse/SSLHttpResponse.

This error happens every time I try to continuously refresh a page. It's quite obvious that it's a result of browser terminating premature requests when refreshing pages. Did I miss something from the docs?

[ghost]

This exact question (in verbatim) was already answered from where you copied it. Read the answer, you clearly aren't handling onAborted. Do you really think, that putting a console.log inside onAborted is "handling it"? As if the library only teased you with mundane tasks that really aren't needed? To handle onAborted is to actually............. Handle, it. It means (like the docs clearly say) the request was aborted and you cannot respond to it.

[lewispham]

Every HttpResponse MUST have an attached abort handler IF you do not respond to it immediately inside of the callback. Returning from an Http request handler without attaching (by calling onAborted) an abort handler is ill-use and will terminate. When this event emits, the response has been aborted and may not be used.

The related doc does not mention the behavior of aborted requests. And your previous answer in the other question didn't help. That's why I have to create another question. What does "may not be used" mean? What happen after a request is aborted? It does not mention the exact exception or its behavior when trying to call response's methods after it is aborted. It's clear now. Thanks.

[ghost]

Nobody is going to hold your hand though this. If you can't connect the dots from the given info you can't connect the dots. That's fine.

[uasan]

What happen after a request is aborted?

in this library, everything is cleared at the moment when it is no longer needed, the request object is cleared in the next microtask, the response object is cleared when the request is completed or abort

instead of the garbage collector, manual management, you should do the same )

[lewispham]

@uasan Thanks for the info. I decided to add a flag directly to the response object for handling aborted requests. As you've said then if I'm not misunderstanding, the request abort status should be check after every async call to avoid unnecessarily holding request and response object in memory. Is that correct?

[uasan]

@lewispham after async call and before access to response object