recaptime.dev / phorge
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Fix a possible deadlock in unit tests after an error

Summary:
After certain types of errors, we may deadlock when trying to destroy test databases.

Specifically, we still have connections open to, say, `phabricator_unittest_abasonaknlbaklnasb_herald` (or whatever) and MySQL sometimes (not sure exactly when?) waits for them before destorying the database.

Test Plan:
- Added `$m = null; $m->method()` to a fixture test to force a fatal.
- Saw consistent deadlock, with `storage destroy` never exiting.
- Added `--trace` to the `storage destroy` command and made it use `phutil_passthru()` so I could see what was happening.
- Saw it hang on some arbitrary database.
- Conneced to MySQL, used `show full processlist;` to see what was wrong.
- Saw the `DROP DATABASE ...` command waiting for locks to release on the database, and other connections still open.
- Applied patch.
- Saw consistent success.
- Used `storage destroy --unittest-fixtures` to clean up extra databases.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14875

epriestley 37f1f555 19b2eb57

+5
+5
src/infrastructure/testing/fixture/PhabricatorStorageFixtureScopeGuard.php
··· 24 24 public function destroy() { 25 25 PhabricatorLiskDAO::popStorageNamespace(); 26 26 27 + // NOTE: We need to close all connections before destroying the databases. 28 + // If we do not, the "DROP DATABASE ..." statements may hang, waiting for 29 + // our connections to close. 30 + PhabricatorLiskDAO::closeAllConnections(); 31 + 27 32 execx( 28 33 'php %s destroy --force --namespace %s', 29 34 $this->getStorageBinPath(),