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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: