[SERVER-43056] Allow specification of errorLabels in failCommand Created: 27/Aug/19 Updated: 06/Dec/22 Resolved: 08/Sep/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Patrick Freed | Assignee: | Backlog - Service Architecture |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
It would be helpful for driver testing if errorLabels could be specified as part of a failCommand failpoint. Alternatively, the errorLabels could simply populated according to the error code's category as they are for real errors. Also, I'm required to set an assignee for this, but wasn't exactly sure where to send it. I apologize in advance if the platform team backlog is not the correct place. Edit: upon further inspection, I've found that the alternative mentioned above is how failCommand currently works. i.e. The server is setting errorLabels according to the category (e.g. 280 and NonResumableChangeStreamError). That makes this work lower priority, but it would probably still be useful if drivers could trigger errors with specific labels in their tests. |
| Comments |
| Comment by Ratika Gandhi [ 08/Sep/20 ] |
|
If this is a higher priority for Drivers, please feel free to reopen this ticket. |
| Comment by Shane Harvey [ 06/Nov/19 ] |
|
This looks like it's now a duplicate of |