sessions_collection_upserts.js asserts a fixed config.system.sessions count that is no longer stable

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 9.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Optimization
    • Fully Compatible
    • ALL
    • 200
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      The jstest sessions_collection_upserts.js hard-codes the number of documents it expects in config.system.sessions after each refreshLogicalSessionCacheNow (1611). This is brittle: the count depends on how many distinct logical sessions ReplSetTest's setup helpers happen to register on the primary before the first refresh, which is not a stable contract.

      Observed on the master Evergreen waterfall (build 9af54bf8, no_passthrough, RHEL 8 enterprise dynamic, all-feature-flags)

      After the first refreshLogicalSessionCacheNow, the test expected count() == 1 (the shell's implicit session), but observed 2.

      In this ticket we fix the assertion error by replacing the hard-coded counts with a baseline snapshot taken after the first refresh, and assert deltas from the baseline.

      This makes the test robust to any future change in the number of internal sessions ReplSetTest leaves behind, while preserving the original behavioral checks (insert and update oplog deltas around the implicit session and the explicitly created/refreshed sessions).

            Assignee:
            Matt Olma
            Reporter:
            Matt Olma
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: