-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
.maintenance.flag and .maintenance.ip files are stored in, and queried from S3 bucket, when S3 storage is enabled. #39047
Comments
Hi @gwharton. Thank you for your report.
Join Magento Community Engineering Slack and ask your questions in #github channel. |
@magento give me 2.4-develop instance |
Hi @makkoff. Thank you for your request. I'm working on Magento instance for you. |
Hi @makkoff, here is your Magento Instance: https://1245dd07a1097aa7fbe5481b12ec95d4.instances-prod.magento-community.engineering |
Hi @engcom-Hotel. Thank you for working on this issue.
|
Hello @gwharton, Thanks for the report and collaboration! It seems to us an expected behavior to check whether the Magento is in maintenance mode or not. And because we enabled the S3, all assets are kept in the S3 bucket only that's why an API has been triggering to check the mode of Magento. Please let us know if we have missed anything here. Thanks |
I agree it is the exected behaviour given the current implementation. I was however querying whether it is the right behaviour. API calls to S3 are chargable per call. Several calls are made to S3 to check if maintenance mode is enabled for every instantiation of the Magento App which both increases costs, and also increases latency to the end user. |
Hello @gwharton, I agree with your point that S3 API calls have been chargeable. Keeping this in mind, I am marking this issue as a feature request for further processing. Thanks |
Yeah, not a bug as such, just could do with improvement. The functionality is well abstracted, so would seem possible to provide a configurable maintenance flag system with options to use
Perhaps configurable through di.xml with the default being the current implementation. Thus giving people the option to keep the maintenance files local if they only run single node for increased speed, or even keep the flag in the database, should that be possible. |
Preconditions and environment
2.4.7-p1
S3 Storage Enabled
Steps to reproduce
Deploy 2.4.7-p1
Enable S3 Storage
Enable Maintenance Mode
Expected result
I wouldn't expect the mechanism to determine whether Magento is in maintenance mode or not to require a remote call to the S3 bucket.
Actual result
Every time my server is hit at the frontend, it fires off an API call to the S3 bucket to check for .maintenance.flag
Additional information
Not a bug as such, but feels like something that crept in without noticing when remote storage was envisaged.
I'm sure there are use cases to have a central .maintenance.flag shared across all instances
Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: