Use service destruction to fix the bug
2 open threads
Closes #3405976
Merge request reports
Activity
- Resolved by Alex Pott
297 * {@inheritdoc} 298 */ 299 public function destruct() { 300 $manager = $this->transactionManager(); 301 if ($manager && $manager->inTransaction() && method_exists($manager, 'commitAll')) { 302 $this->transactionManager()->commitAll(); 303 } 304 305 // BC layer. 306 // @phpstan-ignore-next-line 307 if (!empty($this->transactionLayers)) { 308 // @phpstan-ignore-next-line 309 $this->transactionLayers = []; 310 // @phpstan-ignore-next-line 311 $this->doCommit(); 312 } - Comment on lines +305 to +312
- Resolved by Alex Pott
- Resolved by Alex Pott
added 6 commits
-
3d5006fd...2d17900f - 5 commits from branch
project:11.x
- a5b982bd - Merge branch '11.x' into 3405976-minimal-approach
-
3d5006fd...2d17900f - 5 commits from branch
added 2 commits
127 127 return $this->stack; 128 128 } 129 129 130 /** 131 * Commits the entire transaction stack. 132 * 133 * @internal 134 * This method exists only to work around a bug caused by Drupal incorrectly It would be worth mentioning XDebug develop mode here to avoid a situation where someone thinks the code can be removed because they can’t reproduce the thing it works around.
I also truely believe this isn’t a bug in Drupal - destruction ordering is well defined and reliable in normal operation - it’s just XDebug develop mode causes it to not happen and instead pushes you into end of script destruction which IS unreliable. So rather this is an incompatibility and this code aims to be more compatible with the runtime behaviours introduced by XDebug develop mode
added 31 commits
-
1e4ce10b...71c9b9f7 - 29 commits from branch
project:11.x
- 7d452070 - Fix drupal_rebuild() and other places where we boot the kernel and use the database
- 737f5706 - Merge branch '11.x' into 3405976-minimal-approach
-
1e4ce10b...71c9b9f7 - 29 commits from branch
added 2 commits
Please register or sign in to reply