Accept a document when toggling an IFR flag with setParameter

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution
    • QE 2025-09-15, QE 2025-09-29
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      A setParameter command can enable or disable an Incremental Feature Rollout (IFR) flag by setting it to true or false, but some use cases would benefit from being able to set the flag using a previous output from getParameter, which is a document containing the flag state along with some other information.

      Minimally, setParameter should accept a document formatted as {value: <BOOL>}. It may also be useful to validate the other values from the getParameter output (version, fcv_gated, currentlyEnabled), but it's not necessary.

       

      In more detail:

      Ordinarily, the automation agent looks at the output of getParameter: '*', against the list of all the parameters in its own configuration, and where they differ, run setParameter to bring them into line. E.g.

      admin> db.adminCommand({getParameter: 1, jsHeapLimitMB: 1})
      {
        jsHeapLimitMB: 1100,
        ok: 1,
      ...
      }
      admin> db.adminCommand({setParameter: 1, jsHeapLimitMB: 1000})
      {
        was: 1100,
        ok: 1,
      ...
      }
      admin> db.adminCommand({getParameter: 1, jsHeapLimitMB: 1})
      {
        jsHeapLimitMB: 1000,
        ok: 1,
      ...
      }

      However for IFR flags, it looks like the getParameter structure is an object, where the input to setParameter itself is just a boolean

      db.adminCommand({setParameter: 1, featureFlagPushdownFilterToIXScanWhenUsingIndexForSort: false})
      {
        was: {
          value: true,
          version: '8.2',
          fcv_gated: false,
          currentlyEnabled: true
        },
        ok: 1,
        '$clusterTime': {
          clusterTime: Timestamp({ t: 1756508134, i: 1 }),
          signature: {
            hash: Binary.createFromBase64('bauoZcnI9zNsAbYicMyq6nEAqNo=', 0),
            keyId: Long('7544143616298450947')
          }
        },
        operationTime: Timestamp({ t: 1756508134, i: 1 })
      }
      admin> db.adminCommand({getParameter: 1, featureFlagPushdownFilterToIXScanWhenUsingIndexForSort: 1})
      {
        featureFlagPushdownFilterToIXScanWhenUsingIndexForSort: { value: false, fcv_gated: false, currentlyEnabled: false },
        ok: 1,
        '$clusterTime': {
          clusterTime: Timestamp({ t: 1756508164, i: 1 }),
          signature: {
            hash: Binary.createFromBase64('yAceA4KC069LaNQ1gXC6ZuPsTRE=', 0),
            keyId: Long('7544143616298450947')
          }
        },
        operationTime: Timestamp({ t: 1756508164, i: 1 })
      }

      As a result the agent tries to do a boolean-to-map comparison and the process is never deemed complete.

      For Atlas support, setParameter should support this input value for setParameter: 

      admin.runCommand({setParameter: 1, "featureFlagPushdownFilterToIXScanWhenUsingIndexForSort": {"value": true}}); 

       

      For backwards compatibility, this could potentially be still supported, but is not necessary

      admin.runCommand({setParameter: 1, "featureFlagPushdownFilterToIXScanWhenUsingIndexForSort": true});

      And to re-emphasise, this need only be the case for ifr flags if they are the only ones that return an object for a boolean input. 

            Assignee:
            Victor Ghita
            Reporter:
            Justin Seyster
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: