You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you run Puma in cluster mode in development, you can end up getting a 404 when requesting a new asset (similar issue to #183). I tracked it down to the digest being memoized (introduced in #23). I can't quite reason about why it happens, but the issue is the fresh? check in server will use the old (memoized) digest depending on what puma worker your request hits.
Replication steps I used was to start rails with WEB_CONCURRENCY=2, load a page in the browser, update a javascript file, then refresh the page. The new request will have an updated javascript digest in the script tag, but depending on what puma worker you hit, that memoized digest will be the old one, so the server returns 404.
I removed the memoization of the digest and that fixed the problem, but that may not be desirable.
Maybe the answer is don't run puma in cluster mode in dev, which would be fine for me.
The text was updated successfully, but these errors were encountered:
Digest is memoized because that has a major performance impact in development, specially if your project has thousands of assets.
You mentioned “new” assets, but since removing memoization solves the problem, I believe you mean “changed” assets. In this case, removing memoization is probably not a solution. It simply slowed down assets reload enough to accidentally fix the problem.
I’ve seen 404 happening often when I’m editing css/js files and immediately alt tabbing to browser and reloading. What I believe is happening is that the bundler is deleting the original file, which causes a cache sweep in Propshaft. Then starting the compilation, while Propshaft reloads and recalculates file digests. Then it finishes after Propshaft is done with digests. Which causes 404s
I believe if you reload multiple times the page eventually you get the correct file?
You mentioned “new” assets, but since removing memoization solves the problem, I believe you mean “changed” assets
Yes, I did mean changed assets, which generates a new URL as the digest changed.
I believe if you reload multiple times the page eventually you get the correct file?
No. I made a screencast using a new rails app 8.0.1 with propshaft 1.1.0 and using esbuild. I noticed something new this time, where the first request after changing the JS resulted in a request for the same digested URL, but different content sent form the server. Then, I can't figure out any exact way to repeat the behavior, sometimes subsequent requests work all the time in the browser, but not always using curl. Sometimes the first request after changing the JS works, sometimes it doesn't. None of these problems occur when you use puma in single mode.
If you run Puma in cluster mode in development, you can end up getting a 404 when requesting a new asset (similar issue to #183). I tracked it down to the digest being memoized (introduced in #23). I can't quite reason about why it happens, but the issue is the
fresh?
check in server will use the old (memoized) digest depending on what puma worker your request hits.Replication steps I used was to start rails with WEB_CONCURRENCY=2, load a page in the browser, update a javascript file, then refresh the page. The new request will have an updated javascript digest in the script tag, but depending on what puma worker you hit, that memoized digest will be the old one, so the server returns 404.
I removed the memoization of the digest and that fixed the problem, but that may not be desirable.
Maybe the answer is don't run puma in cluster mode in dev, which would be fine for me.
The text was updated successfully, but these errors were encountered: