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

failpoint triggered by LogicalSessionCacheRefresh

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.3.1, 4.2.2, 4.0.14
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.2, v4.0
    • Sprint:
      Sharding 2019-09-09, Sharding 2019-09-23, Sharding 2019-10-07
    • Linked BF Score:
      28

      Description

      A LogicalSessionCacheRefresh is triggering a failpoint configured in driver's retryable reads tests.

      Here's a log of the failpoint being configured:

      2019-08-28T23:50:02.549+0000 W  COMMAND  [conn770] failpoint: failCommand set to: { mode: 3, data: { failCommands: [ "find" ], errorCode: 91 } }
      2019-08-28T23:50:02.549+0000 I  COMMAND  [conn770] command admin.$cmd command: configureFailPoint { configureFailPoint: "failCommand", mode: { times: 1 }, data: { failCommands: [ "find" ], errorCode: 91 }, $db: "admin", $clusterTime: { clusterTime: Timestamp(1567036202, 335), signature: { hash: BinData(0, 57D9AC22A95A2C0F6B3FC988600F0EBDAE1A3\
      98B), keyId: 6730367942157926402 } }, lsid: { id: UUID("bbcf418f-9ebf-4399-815e-063007855163") } } numYields:0 reslen:163 locks:{} protocol:op_msg 0ms
      

      And here's a log of the failpoint being triggered:

      2019-08-28T23:50:02.618+0000 I  COMMAND  [LogicalSessionCacheRefresh] Failing command 'find' via 'failCommand' failpoint. Action: returning error code 91.
      2019-08-28T23:50:02.618+0000 D1 -        [LogicalSessionCacheRefresh] User Assertion: ShutdownInProgress: Failing command due to 'failCommand' failpoint src/mongo/db/commands.cpp 534
      2019-08-28T23:50:02.619+0000 D1 COMMAND  [LogicalSessionCacheRefresh] assertion while executing command 'find' on database 'config' with arguments '{ find: "system.sessions", filter: { _id: { $in: [ { id: UUID("896c9ac8-e5c4-4205-85c0-506610731f71"), uid: BinData(0, 225D5B72D8EF7D8440D09A4B518E1795ED84E9BC3E28CD58A4CAF8C79DAA1A01) }, { id: UUID("bcc718a3-c2\
      ab-44f2-98f9-2bbcf323d8fa"), uid: BinData(0, 225D5B72D8EF7D8440D09A4B518E1795ED84E9BC3E28CD58A4CAF8C79DAA1A01) }, { id: UUID("574be726-cac4-41ca-bd71-c770413c8863"), uid: BinData(0, 225D5B72D8EF7D8440D09A4B518E1795ED84E9BC3E28CD58A4CAF8C79DAA1A01) }, { id: UUID("b25e9f15-87d5-467a-8ccf-de5d88ae4d24"), uid: BinData(0, 225D5B72D8EF7D8440D09A4B518E1795ED84E9BC\
      3E28CD58A4CAF8C79DAA1A01) }
      

      Driver tests expect that, by default, internal commands like this do not trigger failpoints.

      This is a significant bug for drivers because tests fail in apparently random fashion based on the timing of the background processes running in the server, resulting in difficult to debug test failures.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              misha.tyulenev Misha Tyulenev
              Reporter:
              jeff.yemin Jeffrey Yemin
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: