[SERVER-39292] Fail point `failCommand` is evaluated twice when `writeConcernError` is specified Created: 30/Jan/19 Updated: 29/Oct/23 Resolved: 07/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.8 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matt Broadstone | Assignee: | Janna Golden |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Sharding 2019-02-11 |
| Participants: |
| Description |
|
We're using the failCommand fail point for the "Convenient API for Transactions" spec tests to return a write concern error on commitTransaction. The following shell script generally reproduces the issue we're encountering:
After investigating with mark.benvenuto, it appears that because closeConnection and writeConcernError are both specified, the fail point is activated twice: first here, then here. If closeConnection: false is removed, or {{ mode: { times: 4 } }} is specified, then the fail point operates as expected. |
| Comments |
| Comment by Shane Harvey [ 10/Dec/20 ] |
|
janna.golden, is there any way this bug fix can be backported to 4.0? |
| Comment by Githook User [ 07/Feb/19 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |
| Comment by Janna Golden [ 07/Feb/19 ] |
|
I pushed a fix for the double decrement, but you should not be passing `closeConnection` when passing `writeConcernError` as an option to the failpoint. |
| Comment by Gregory McKeon (Inactive) [ 04/Feb/19 ] |
|
kaloian.manassiev can someone take a look at this this sprint? |
| Comment by Mark Benvenuto [ 04/Feb/19 ] |
|
Assigning to sharding since natalie.tsvetkova made the change inĀ |