[SERVER-44466] Add "errorDocument" field to failCommand fail point Created: 06/Nov/19  Updated: 06/Oct/20  Resolved: 30/Mar/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Shane Harvey Assignee: Spencer Brody (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
duplicates SERVER-42239 Add support for extraInfo in failCommand Closed
Related
related to SERVER-51196 Add "errorMessage" field to failComma... Backlog
related to SERVER-51297 Allow writeErrors to be specified via... Backlog
related to SERVER-47535 Ability to mock command responses on ... Closed
Backport Requested:
v4.4, v4.2
Sprint: Service Arch 2020-04-06
Participants:

 Description   

Drivers use the failCommand fail point extensively in spec tests. It seems that with each server release we need to add a new knob to this fail point in order to test new features. In 4.0 we added the "writeConcernError" field (SERVER-35083). In 4.4 we're adding the "errorLabels" field (SERVER-43941).

It might be useful to add a way for the command to specify the entire error document to return instead of just the error code or the errorLabels. For example:

db.adminCommand({
    configureFailPoint: "failCommand",
    mode: "alwaysOn",
    data: {failCommands: ["find"], errorDoc: {ok: 0, code: 2, errmsg: "my error message", errorLabels: ["Label"]}}
});
// Returns {ok: 0, code: 2, errmsg: "my error message", errorLabels: ["Label"]}
db.runCommand({find: "collection"});
db.adminCommand({configureFailPoint: "failCommand", mode: "off"});

This would also satisfy SERVER-42239 since the user could add "extraInfo" to the errorDoc.



 Comments   
Comment by Spencer Brody (Inactive) [ 30/Mar/20 ]

Doing this requires direct access to the ReplyBuilderInterface, which is something we're trying to remove as part of the "Communicate command failures with exceptions, not BSONObj" project.
On top of that, I worry that this isn't the right approach. Using this approach would require the drivers to keep their tests that use this
updated as the error responses on the server change, which seems to eliminate the whole value of plugging into the server's error generation system in the first place.

For these reasons, I am proposing that we not do this ticket.

Comment by Shane Harvey [ 24/Feb/20 ]

Neat, thanks! However I can't seem to get errorExtraInfo to work on v4.3.3-300-gbc9eb30:

> db.adminCommand({     configureFailPoint: "failCommand",     mode: {"times": 1},     data: {failCommands: ["find"], errorCode: 2, errorExtraInfo: {"errorLabels": ["ExtraLabel"], "extraField": 1}} });
{
	"count" : 178,
	"ok" : 1,...
}
> db.runCommand({find: "collection"});
{
	"ok" : 0,
	"errmsg" : "Failing command due to 'failCommand' failpoint",
	"code" : 2,
	"codeName" : "BadValue"
}

Does errorExtraInfo require threadName as well?

Comment by Carl Champain (Inactive) [ 07/Nov/19 ]

Hi shane.harvey,

Passing this ticket along to the Server Development Platform team.

Generated at Thu Feb 08 05:06:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.