-
-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Corrupted file served if file is changed during serving. #155
Comments
Hi @wdanilo that is strange indeed! This module doesn't perform any type of internal caching of anything, from the file content to any other metadata. Each request for a given file is looked up in the file system and read a-new every time. The reading is done using the I could try and help debug the cause if I can get the exact code and steps to reproduce the issue, though. |
@dougwilson thanks so much for fast reply, so detailed answer, and that you are willing to help us. I appreciate it a lot! Unfortunately, this issue is not easily reproducible on our end, as it happens sometimes, when certain conditions are met (we are unsure what are these conditions yet, we have only observed that it happens when the WASM file is being regenerated during serving). We will try to configure the code to reproduce it on every build and we will get back to you :) |
The problem is likely that you are modifying the file in-place on the filesystem when regenerating it. Instead, generate the new version under a different filename, and then move it to replace the old one. This way a single read stream of the file will either get the complete old or complete new version of file. |
Under the hood, serve-static uses the send package, and there is a race condition in that package, ie if the file contents changes after the fs.stat call but while streaming is still going to the client, the contents received by the client will be corrupted. Reference to the issue here: The relevant code snippet:
I am also experiencing this issue, where Express serves a PNG back to the browser. If the PNG content gets overwritten while Chrome is getting the image, it will be appear corrupted on the webpage. Note: Even if you did a "write to temp file" and atomically rename to destination file (ie what @autopulated suggested), it is still susceptible to the race condition above. |
Hi, I've got such a code for my server:
And we have observed a very interesting behavior. Namely, when it is serving our WASM file (100MB+), if the WASM is being re-build just when serving starts, then it is served to the browser corrupted. What's interesting is that after it is rebuilt, browser refreshes dont help - the same corrupted file is being served. What helps is restarting the above server to serve non-corrupted file. Does anyone have any idea why this happens and if this can be prevented somehow? I'm OK with serving it in a corrupted state for the first time (during rebuild), but I want the file to be served correctly after page reload.
The text was updated successfully, but these errors were encountered: