I'm not sure, but I have a strong suspicion that a !fix_double_redirects command I tried failed because of Heroku's (not entirely undeserved) security obsession:
Heroku rotates credentials periodically and updates applications where this database is attached.
When deployed, the env var DATABASE_URL specifies where ESAEBSAD3 connects to. Currently, we only do the connection once, when everything is initialized. If this env var changes (which I suspect is the case here), then this means ESAEBSAD would fail to connect to the DB, since it would be relying on the outdated url. I'm not completely sure though, and will need to test this.
Solution is pretty easy but requires some refactoring: use a method to get an instance of the DB each time instead of accessing it directly, and have it check if the env var changed. This will result in a lot of redundant changes of course, but performance-wise checking local env vars is peanuts compared to querying a database.
I'm not sure, but I have a strong suspicion that a
!fix_double_redirects
command I tried failed because of Heroku's (not entirely undeserved) security obsession:When deployed, the env var
DATABASE_URL
specifies where ESAEBSAD3 connects to. Currently, we only do the connection once, when everything is initialized. If this env var changes (which I suspect is the case here), then this means ESAEBSAD would fail to connect to the DB, since it would be relying on the outdated url. I'm not completely sure though, and will need to test this.Solution is pretty easy but requires some refactoring: use a method to get an instance of the DB each time instead of accessing it directly, and have it check if the env var changed. This will result in a lot of redundant changes of course, but performance-wise checking local env vars is peanuts compared to querying a database.