Skip to content
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

cache_sweeper doesn't work with puma cluster mode #228

Open
davekaro opened this issue Jan 3, 2025 · 2 comments
Open

cache_sweeper doesn't work with puma cluster mode #228

davekaro opened this issue Jan 3, 2025 · 2 comments

Comments

@davekaro
Copy link

davekaro commented Jan 3, 2025

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.

@brenogazzola
Copy link
Collaborator

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?

@davekaro
Copy link
Author

davekaro commented Jan 4, 2025

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.

Screen.Recording.2025-01-03.at.9.56.10.PM.mp4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants