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
This is not a bug but a limitation of the current system. That is heroku depoloyments cannot benefit from the approach being used with the management on|off command.
Any execution of heroku run manage.py will be run on a separate worker dyno, not the web one. Therefore the lockfile is set but on the wrong machine.
It would be nice to have a dynamic approach that works for Heroku. It seems like the most obvious thing is to maintain the flag in a DB table instead of in the filesystem.
Another possible workaround is providing a a staff-authenticated URL route which togged the maintenance status by adding/removing the file.
The text was updated successfully, but these errors were encountered:
This is not a bug but a limitation of the current system. That is heroku depoloyments cannot benefit from the approach being used with the management on|off command.
Any execution of heroku run manage.py will be run on a separate worker dyno, not the web one. Therefore the lockfile is set but on the wrong machine.
It would be nice to have a dynamic approach that works for Heroku. It seems like the most obvious thing is to maintain the flag in a DB table instead of in the filesystem.
Another possible workaround is providing a a staff-authenticated URL route which togged the maintenance status by adding/removing the file.
The text was updated successfully, but these errors were encountered: