system.schema information gets out of sync with module list

Can I ask for a bit more context as to what "gets out of sync" means

I see #3

which is about orphaned, as opposed to missing, system.schema information, but let's track them together for now until we have an idea of how this is getting out of sync.

Even vague recollections of the bug would be useful in mapping 'missing system.schema information' to "write path failures" or "read path failures".

In terms of broad-scoped behat tests this is what I mean.

The read path test:-
When the database table 'key-value' rows are set like so .. then when I visit '/admin/modules' I should see x, y, z

The write path tests:-
When I visit '/admin/modules' and click here. here and here .. then the tables should look like a, b, c

From that quote missing 'system.schema information' looks like a write path failure.

But was access through drush, or the 'admin/modules' page

This might be useful as the admin/modules controller always reads the state of the modules with a little reset() thrown in

 $modules = $this->moduleExtensionList->reset()->getList();

If the bug report said "All I know is that we are seeing random tests failures" .. that would also be valid and I would approach the problem differently.

I used to reproduce kind of it with ActionConfigTest after removal of cachable call in drupal_load_updates() to drupal_get_installed_schema_version(NULL, FALSE, TRUE) with new service #2124069-288: Convert schema.inc to the update.update_hook_registry service (UpdateHookRegistry)

It allowed to catch that tests should write initial schema, so maybe when module enabled via config install it does not write schema update

One way for things to get out of sync is for the container rebuild during

        // Update the kernel to include it.
        $this->updateKernel($module_filenames);

to throw an exception. I think this can occur quite easily due to broken code or incorrect assumptions made by a module. Is it a silly idea to consider trying to a module install (or unisntall) inside a database transaction - and therefore if anything goes wrong we can rollback?

Another case is from config-slack - it's often used $settings['config_exclude_modules'] = ['devel', 'stage_file_proxy']; but I found no "schema changes" in config transformations

@andypost I'm not sure about #11. It's not working the way you think it is. If the site already has devel installed on it that adding that to config_exclude_modules is not going to uninstall it.

Reset issue status.

Module install not being atomic can also lead to "Cannot update database because 'module is too old'".
See #3206215-11: "The installed version of the <Module> module is too old to update" makes no sense to site administrators.