ExportXMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Unknown
    • None
    • Component/s: Change Streams
    • 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 change streams spec requires a resume after any non-server error, including the application canceling the getMore operation from next (Go, .NET with CancellationToken, Node?, Python (async API), Rust?, Java with Thread#interrupt and Structured Concurrency), and nothing requires the driver to keep the cursor ID when the resume's kill fails, which orphans the cursor:

      Any error encountered which is not a server error (e.g. a timeout error or network error)

      The bug works like this:

      1. app opens a change stream; the server creates a cursor for it
      2. app calls next and the driver sends a getMore that waits for new events
      3. app cancels the operation while the getMore is waiting
      4. getMore fails with a cancelation error, which is not a server error, so the spec says it's resumable
      5. driver resumes, trying to kill the old cursor before running a new aggregate
      6. killCursors uses the same cancelation context, so it fails before anything reaches the server
      7. the server cursor is orphaned. In Go, the ID is zeroed, so close has nothing to kill
      8. the server cursor stays open until it times out (10 minutes by default)

      Motivation

      Who is the affected end user?

      Applications that call next on a change stream with a context they cancel or put a deadline on.

      How does this affect the end user?

      Unclear, wastes server resources and probably confusing metrics.

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

      Any change stream user who cancels or times out a next call is affected, which seems fairly likely.

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

      Each canceled next leaves an orphaned cursor on the server for up to 10 minutes. Probably minor resource contention.

      Is this issue urgent?

      Not completely clear but almost certainly not urgent. Hesitation comes from cancelation misuse or really tight deadlines: e.g., racing network latency.

      Is this ticket required by a downstream team?

      No

      Is this ticket only for tests?

      No

      Acceptance Criteria

            Assignee:
            Unassigned
            Reporter:
            Preston Vasquez
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: