Use Case

As a Node.js user of cursor
I want to rely on the fact that cursor.next() should never return the same document twice 
So that I don't accidentally handle duplicate data

User Experience

• What is the desired/expected outcome for the user once this ticket is implemented?
  • Cursors never run a getMore when one has already started.
• If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?
  • This is difficult to reproduce in normal usage. Folks need to employ concurrency (un-awaited promises) and have small batch sizes that match the number of parallel promises in order to get duplicate documents. However, we believe this guardrail is an easy safety change to make to prevent surprising results.

Dependencies

• upstream and/or downstream requirements and timelines to bear in mind
  • None

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
  • Low risk.
• Is there an opportunity for better cross-driver alignment or testing in this area?
  • Possibly, this is likely something drivers with threads document rather than prevent.
• Is there an opportunity to improve existing documentation on this subject?
  • Yes, we should document this behavior on the cursor APIs that are relevant

Acceptance Criteria

Implementation Requirements

• Following the pattern in client connect, do not create a new getMore promise if one exists.

Testing Requirements

• Add tests using change streams and normal find cursors in parallel. (Promise.allSettled)

Documentation Requirements

• Add API docs

Follow Up Requirements

• None
• if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward