Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-51196

Add "errorMessage" field to failCommand failpoint and ability to toggle error code

    • Type: Icon: New Feature New Feature
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Query Execution

      Error handling in drivers currently relies on message substring checks for "not master" and "node is recovering". It is used to help determine whether an error is a server state change error per SDAM, or if it is a retryable read / write error. We intend to remove those checks in DRIVERS-1152, but we are unable to test it with our existing SDAM integration test runner. The test runner uses the failCommand failpoint to simulate errors. But failCommand responses have a fixed errmsg: "Failing command due to 'failCommand' failpoint", so we cannot check the substring matching behavior.

      If possible, could the failCommand arguments have an additional errorMessage field to overwrite or append to the returned errmsg? Here is an example API proposal:

      db.adminCommand({
          configureFailPoint: "failCommand",
          mode: "alwaysOn",
          data: {failCommands: ["find"], errorMessage: "node is recovering", errorCode: 123}
      });
      // Returns {ok: 0, code: 123, errmsg: "node is recovering" }
      db.runCommand({find: "collection"});
      db.adminCommand({configureFailPoint: "failCommand", mode: "off"}); 
      

      Secondly, drivers error handling checks for the presence of an error code. Older MongoDB servers may not return an error code in all cases. Would it be possible to make errorCode optional so we can test the omission of an error code?

            Assignee:
            backlog-query-execution [DO NOT USE] Backlog - Query Execution
            Reporter:
            kevin.albertson@mongodb.com Kevin Albertson
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: