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.
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.