PHPLIB-1531: Retry once when disabling fail points#1445
PHPLIB-1531: Retry once when disabling fail points#1445jmikola merged 1 commit intomongodb:v1.20from
Conversation
jmikola
force-pushed
the
1.20-phplib-1531-failpoints
branch
from
2004e98 to
14ec9f0
Compare
jmikola
force-pushed
the
1.20-phplib-1531-failpoints
branch
from
14ec9f0 to
fea8b2a
Compare
| $operation = new DatabaseCommand('admin', ['configureFailPoint' => $failPoint, 'mode' => 'off']); | ||
| $operation->execute($server); | ||
| } catch (ConnectionException $e) { | ||
| // Retry once in case the connection was dropped by the last operation |
There was a problem hiding this comment.
I'm still at a loss for why this wasn't an issue with the original FailPointObserver. There, the Server object was instantiated from the CommandStartedEvent; however, it's just an integer server_id and Manager reference. That's not much different from the object we're capturing here from configureFailPoint(). In both cases, the command to disable a fail point is still being executed via phongo_execute_command() with the same underlying mongoc_client_t and server_id.
The only difference I can identify is when we're disabling fail points. Previously, FailPointObserver disabled fail points during our equivalent of a tearDown() method. Now, we're doing so immediately after executing operations and before evaluating expectEvents (note: this is what the spec itself suggests). It's possible the previous deferral allowed some opportunity to reestablish a dropped connection.
This may be related to CDRIVER-4532, which highlights an outstanding libmongoc deficiency in the code paths utilized by PHPC.
* Retry once when disabling fail points (#1445) The previous refactor in 90dcf18 changed when we disable fail points. ManagesFailPointTrait now does so immediately after test operations are run instead of during tear down, so we may be hitting a point where the server stream was disconnected and libmongoc is not recovering (possibly related to CDRIVER-4532). Adding an extra retry attempt seems to overcome this. * Use non-capturing catch statement --------- Co-authored-by: Jeremy Mikola <jmikola@gmail.com> Co-authored-by: Andreas Braun <andreas.braun@mongodb.com>
2 participants
https://jira.mongodb.org/browse/PHPLIB-1531
This is an attempt to resolve flaky test failures following #1427