Request timeout measurement with stopwatch in NetworkInterfaceTL is off

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • 9.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Networking & Observability
    • ALL
    • N&O 2026-03-30
    • 200
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Regarding the fix for BF-42088, it improved the gap between expected and actual wait time but didn't address the fundamental change from the PR that moved the now() baseline from CommandStateBase to RemoteCommandRequest , introducing a potential small discrepancy between different clocks. While locally addressing the truncation issue was enough for the test, on Evergeen the issue persists, just with a smaller gap. There are multiple things that can be done, but they generally fall into two categories: fixing the test and fixing the way the time is measured. The deadline logic is complicated now - the deadline gets created in the RemoteCommandRequest then gets adopted by CommandStateBase. In some cases, its lifetime starts even earlier in OpCtx. I imagine there could be a way to properly preserve the underlying intent of maintaining different deadlines that solve the original problem and separate concerns at the same time, but that would be time consuming.
      This issue is not a production problem. In the spirit of moving fast, I can just add that one millisecond to the assertion in the test and move on to actual problems.

            Assignee:
            Sergei Bazhenov
            Reporter:
            Sergei Bazhenov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: