mirror of
https://github.com/eitchtee/WYGIWYH.git
synced 2026-01-15 05:33:26 +01:00
Database connection is closed and never reopened #74
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zkutasi on GitHub (Nov 28, 2025).
Right after deployment, everything works fine...
But I have left the tool idle for a day and returned to it the next day.
Now I have a working UI but any DB transaction goes like this in the logs:
I then delete the Pod (mind you I am deploying on Kubernetes), and everything works again.
@eitchtee commented on GitHub (Nov 28, 2025):
I suppose you don't have the logs for this anymore, but was this blocking normal UI behavior, like adding new transactions?
I've seen this happen with the background tasks, but it seems to be random, it should be related to https://github.com/procrastinate-org/procrastinate/issues/1134. Usually restarting the dabatase and application fixes the issue.
But I haven't seen it happen on the normal Django thread, specially in such a short time. If this happens again, let me know.
@zkutasi commented on GitHub (Nov 29, 2025):
Yes, this blocks nearly everything that requires modification in the DB... and those are silently dropped... like... I wanted to try your idea how to trigger Rules on an already loaded transaction (trigger on update + unpaid/paid switch), and for 1 hour it did not work, then I remembered this other issue I had, so I recreated the Pod, and voila.
This is the log I have:
And for a few dozen times, the last error, until I restarted the Pod.
Like this one is the last occurrence:
@eitchtee commented on GitHub (Dec 6, 2025):
Next release will have a possible patch for this (possible because I can't reliably test this). I've closed the issue, but let me know if you still encounter this problem in the future.
@zkutasi commented on GitHub (Dec 19, 2025):
Thanks!
Unfortunately it came again with 0.18.1, in this flavor:
I got a Server 500 when I wanted to click on anything... so I deleted my Pod and now it works again.
Maybe a workaround might be to constantly use the DB connection? I am trying to figure out how, maybe by doing an automatic exchange rate checker.
@eitchtee commented on GitHub (Dec 20, 2025):
Very sorry about this. Not sure why you're the lucky one facing these issues.
Are you using a brand new postgres instance (e.g. the one provided in the docker-compose) or connecting to an existing instance? Maybe your postgres instance is very eager to close existing connections due to some configuration or lack of resources?
Either way I will release a different fix for this, fingers crossed it works this time.
Django has a built-in health check option, meaning it pings the database before using the connection, if it's dead it will create a new connection (which is somewhat similar to your suggestion). My fear about using this was performance, but there's no mention of it in the documentation, so I'm trusting it's fine.
@eitchtee commented on GitHub (Dec 20, 2025):
I will try to release this fix this Sunday, please let me know if you still have problems.
@zkutasi commented on GitHub (Dec 20, 2025):
I am using Kubernetes, so I took your provided docker-compose, and use TrueCharts' library chart to generate a workload for me, with Cloud Native Postgres (CNPG). It may very well be that the default config in CNPG is not suitable for your app... but I am selfhosting a lot of things due to try-and-see and never encountered such issues before with others (though your stack might be unique of course).
I have tried to do an automatic exchange conversion to perhaps keep the DB open, but the default 24 hours still gave me the 500 error. Mind you, this error is very visible now, as it crashes the app itself for me, so no problem finding it out now :). I now set the interval to 4 hours, I wonder if this would help.
Another workaround I think would be worth it is to implement a health-check on kubernetes Pod level, so the system could restart the container itself when this happens.
@eitchtee commented on GitHub (Dec 20, 2025):
I have 0 experience with k8s, so I might not be very helpful in this instance. 0.18.3 will be released tomorrow, it implements the health-checks for database connections which I think has a lot of potential in fixing this, let me know how it goes.
Feel free to re-open this issue if you encounter problems again.
@max-wittig seems to have had some relative success recently with his k8s instance, maybe he could give out some tips or his configuration.