Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2952

Clarify that drivers should iterate results cursors before retrying bulkWrite

    • Type: Icon: Spec Change Spec Change
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Component/s: Bulk API
    • None
    • Needed
    • Hide

      Summary of necessary driver changes

      •  

      Commits for syncing spec/prose tests
      (and/or refer to an existing language POC if needed)

      •  

      Context for other referenced/linked tickets

      •  
      Show
      Summary of necessary driver changes   Commits for syncing spec/prose tests (and/or refer to an existing language POC if needed)   Context for other referenced/linked tickets  

      Summary

      The bulkWrite command response can contain both a retryable write concern error and a results cursor with a nonzero ID. The bulk write spec does not currently specify whether drivers should iterate the results cursor before or after attempting to retry the bulkWrite. Iterating the results cursor after the retry attempt may leave multiple cursors open (i.e. the initial results cursor and the retry results cursor), so drivers should be required to iterate the results cursor before retrying. Note that drivers cannot discard/kill the original cursor before the retry because the retryable writes spec mandates returning the original error in some cases.

      Motivation

      Who is the affected end user?

      This can potentially impact any users performing bulk writes with the client-level API.

      How does this affect the end user?

      Cursors may be left open on the server and multiple connections may be pinned to cursors driver-side if the driver waits to iterate the cursor until after retrying.

      How likely is it that this problem or use case will occur?

      This is an edge case. The user would need to encounter a retryable write concern error and receive enough results/errors in the cursor to warrant multiple batches.

      If the problem does occur, what are the consequences and how severe are they?

      The consequences of leaving an extra cursor open are unnecessary use of server resources and potential connection pool exhaustion. This is unlikely to be a severe issue but could be problematic if the user has a small maxPoolSize configured.

      Is this issue urgent?

      This is likely an uncommon situation, but resolving this ticket soon will allow drivers to do this work as part of their initial bulk write implementation.

      Is this ticket required by a downstream team?

      No.

      Is this ticket only for tests?

      No.

      Acceptance Criteria

      • Clarify in the bulk write spec that results cursors should be iterated before retrying
      • Add a test to ensure that when a bulkWrite response contains a write concern error and a nonzero cursor ID, the sequence of command started events is [bulkWrite, getMore, bulkWrite, getMore]

            Assignee:
            Unassigned Unassigned
            Reporter:
            isabel.atkinson@mongodb.com Isabel Atkinson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: