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
Intermittent failure in offline compression tests. #1082
Comments
This might be an actual bug, not a broken test, but not sure. The "compress" management command runs tasks using a threadpool and 4 workers. The base.html:
and test_compressor_offline.html:
Both templates have an identical I instrumented the code to print the traceback for the underlying "No such file or directory" exception, here it is:
So, compressor calls
I'm guessing there's a race condition where concurrent threads save the same file, one thread deletes it and then the other thread tries to chmod it. |
@carltongibson I'm cautiously optimistic this fixes the intermittent test failures: #1086 |
Hey @cuu508 - thanks for this! I'll take a look now. 🥇 |
compressor avoids rendering the same node multiple times by checking for a key in offline_manifest: ``` if key in offline_manifest: continue [... render template ...] offline_manifest[key] = result ``` Multiple _compress_template calls can run concurrently, creating a race condition: each checks for a key in offline manifest, then each proceeds to render template. Finally they try to save the same file at the same time, causing #1082. My proposed fix is to atomically * check if the manifest key exists * if it doesn't exist, set it to a placeholder value (None) So, in nutshell, the first "if" part becomes: ``` with offline_manifest_lock: if key in offline_manifest: continue offline_manifest[key] = None ``` I'm not sure where to store the lock, I've put it at the module level currently. Perhaps there's a way to avoid the lock entirely.
example: https://github.com/django-compressor/django-compressor/runs/4285761036?check_suite_focus=true#step:5:36
Doesn't happen every run.
The text was updated successfully, but these errors were encountered: