-
Notifications
You must be signed in to change notification settings - Fork 6
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
The S3 upload_assets routine can fail on pod startup, resulting in pages referencing S3-hosted files that don't exist #208
Comments
It seems like the behaviour must be logged somewhere (and if it isn't perhaps there's a logging level we can adjust). There's |
Saw this in the logs:
|
This should be fixed by now, as not using the stored state, if the pod restarts it should upload the assets correctly. Besides, the assets are now precompiled in the rock, so they will not change if the image does not change. |
Bug Description
It's possible for Discourse to fail its S3 upload_assets routine after a restart, resulting in errors like the one above.
The HTML served from the pods loads fine, but the e.g. Javascript URLs referenced within are for paths expected to be created by the upload_assets routine, but which were never uploaded to S3.
This results in a broken page with a spinner, the main content never appears.
To Reproduce
Deploy the application with s3_enabled=True and all associated config set.
Wait for (or force) a restart.
Be unlucky enough to experience this bug (it's unclear how/why it happened).
Environment
This is running on an Openstack cloud, with S3 integration enabled.
Relevant log output
This behaviour doesn't appear to be logged, a simple solution might be to add retry logic to the `image/scripts/pod_setup` script, if I'm understanding how this works correctly.
Additional context
No response
The text was updated successfully, but these errors were encountered: