Keep a MySQL deployment on MySQL, and stop the last admin disappearing
A legacy copy of DatabaseManager.__init__ was defined at the bottom of
database.py and patched over the real constructor at import time. It predates
connection pooling and never sets self._mysql_pool, so the first query on a
MySQL-backed manager raises AttributeError. main.py swallows that into
"Failed to initialize database", which leaves the registry empty, so the next
(config-less) get_config_database() call silently registers the DEFAULT SQLITE
database instead. A MySQL deployment therefore migrates itself to an empty
~/.aisbf/aisbf.db without saying so. On aisbf.cloud that happened on
2026-07-22 and split the user table across two databases for three months.
The real constructor already handles both backends, so the patch is deleted
rather than repaired; the only behaviour it carried that the real one lacked -
a config-less cache manager getting its own file and schema - is folded in.
Separately, nothing prevented an installation from losing its last admin.
/dashboard/delete-account checks the password but not the role, admin user
management will delete anyone, and no dashboard page can mint a new admin, so
the first two are one click away from locking everybody out of user
management, settings and the market admin pages. The same installation sat
with 782 users and zero admins until a row was written by hand. The guard
goes in the database layer, not the route, so every caller is covered:
delete_user() and update_user() now raise LastAdminError instead of removing,
demoting or deactivating the only active admin.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment