Problem/Motivation
See longer explanation on #2572283: Neither REPEATABLE READ nor READ COMMITTED transaction isolation levels are always appropriate.
Request 1 - enables a module
Request 2 - visits the modules page in between the module being enabled and the router being rebuilt, gets a fatal error from the permissions/help links in the module UI.
The chance of getting the fatal error is quite slim (except on fgci, but we'll have a separate issue for that), so major, but it's a fatal error so 'very major'.
Proposed resolution
Have a single transaction which encompasses both the module enable and the route rebuild.
This will be a challenge because the route rebuild happens in Kernel::terminate()
Comments
Comment #2
dawehnerThe general tricky bit is how we deal with generic storages and keeping transactions at the same time.
Comment #3
catchWe have #1679344: Race condition in node_save() when not using DB for cache_field open for part of that.
While this is also an issue, I'd be happy here if we just get things working with one storage layer that actually supports transactions first.
General note I tagged this RC target because it's a race condition and potential fatal error, but it should result in permanent data integrity issues/error state.
Comment #4
cilefen CreditAttribution: cilefen commentedPossibly related: #2684189: RouteNotFoundException: Route "dblog.overview" does not exist when uninstalling the dblog module
Comment #5
xjmComment #7
alexpottThis is less of a challenge and a problem because of #2589967: Rebuild routes immediately when modules are installed
Comment #8
catchDiscussed with xjm, effulgentsia, alexpott and we decided to move this to major task. The original bug is gone, but module enable could be significantly more robust.
Comment #9
TravisCarden CreditAttribution: TravisCarden as a volunteer commented#2795429: RouteNotFoundException thrown when module providing route and module providing menu link are installed separately may be an instance of this issue. In my testing, it's 100% reproducible.
Comment #14
landsman CreditAttribution: landsman commentedHi guys,
I have maybe same problem or not - rather I'll write it here than to be quiet :)
I had installed module "infinite_scroll" and I applied it to my View UI as pager. After some time I uninstall this module and go to view edit page (admin/structure/views/view/front/edit/my_display) I can see this exception:
A cleared cache not works for sure.
I saw these exception more If I was experimenting with some modules and solution was:
1. add back module to the composer,
2. install it again,
3. remove all relationships in drupal admin,
4. uninstall module,
5. remove it from the composer
But these steps are really annoying and I think that here can be some fallback for this situation with remove this relationship in view & switch it to default pager. What you think? Is it related problem with this issue or not?
Thanks