This was detected while re-installing different databases in MDL-38972 testing.

After a bunch of trial and error iterations, here there are some reliable reproduce instructions:

1) Install a new 2.5 site. tables, admin user and frontpage settings.

2) Using your fav DB admin tool, drop all the tables.

3) Install 2.5 again (reusing the existing config.php). Bot the web interface and the install_database.php CLI lead to the same, next, error:

Debug info: Table 'moodle_gitintegrationmaster.mdl_glossary_formats' doesn't exist

SELECT * FROM mdl_glossary_formats WHERE name = ?

[array (

0 => 'continuous',

)]

Error code: dmlreadexception

Stack trace:

line 426 of /lib/dml/moodle_database.php: dml_read_exception thrown

line 1005 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()

line 1401 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->get_records_sql()

line 1373 of /lib/dml/moodle_database.php: call to moodle_database->get_record_sql()

line 1352 of /lib/dml/moodle_database.php: call to moodle_database->get_record_select()

line 919 of /mod/glossary/lib.php: call to moodle_database->get_record()

line 52 of /mod/glossary/settings.php: call to glossary_get_available_formats()

line 3380 of /lib/pluginlib.php: call to include()

line 17 of /admin/settings/plugins.php: call to plugininfo_mod->load_settings()

line 6379 of /lib/adminlib.php: call to require()

line 6399 of /lib/adminlib.php: call to admin_get_root()

line 1487 of /lib/upgradelib.php: call to admin_apply_default_settings()

line 188 of /admin/index.php: call to install_core()

The same procedure has been used with 2.4 over 2.4 and also with 2.5 over 2.4 and the problem IS NOT reproducible with those combinations. Only 2.5 over 2.5 exhibits it.

Also, ignore the glossary/settings.php script, it's horrible, old and not good at all (it comes from a pre-subplugins age and nobody has moved it to proper subplugins).

No matter install_core() calls to cache_factory::disable_stores()... at some point they are accessed (reset happening without notice?) and they have there the information (plugins...) from the previous installation (step 1 above).

Just adding a simple call to cache_helper::purge_all(); ensures that all the caches are cleaned (as they should be on install) and then the problem stops happening.

So here it's a simple patch adding that extra cleanup. It should fix this problem and any future one caused by incorrect "reuse" of caches on re-installation.

In the side of the curiosities, here there are 3:

C1) The CI servers never have presented this problem. They use a new dataroot on each execution so no cache information is there ever.

C2) phpunit initialization (or drop & recreation) never have presented this problem. Surely it's because caches are reset on each test execution.

C3) the muc/config.php file "survives" reinstallation. Not sure if consider that a feature or a bug. In my case it's a feature, as far as I'm using all sort of memcached/doubles/triples combinations and it's nice to have them working all the time, no matter the dev sites are re-installed.

And this is all. Note that, while the suggested patch solves the problem and I've not been able to break a reinstallation anymore, I'm not sure if it's the real problem or the problem is the call to disable_stores() not really disabling them (session ones being the problematic perhaps?).

In the other side, it does not hurt to have that explicit purge_all() to ensure all the configured caches are really empty at that stage.

So, for your entire considerations!