Use Case

As a... Change stream user
I want... to be aware that I haven't subscribed to error events
So that... I don't risk uncaught exceptions

User Experience

• What is the desired/expected outcome for the user once this ticket is implemented?
  • If a tick has passed after adding a change listener and there is still no error listener user's would be informed in someway that they are risking crashing their process

Dependencies

• EventEmitter

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
  • Perhaps the default behavior is desirable
  • Where do you deliver this message if not via an uncaught error
  • Do we consider it a requirement to listen to errors or optional?
• Is there an opportunity for better cross-driver alignment or testing in this area?
• Is there an opportunity to improve existing documentation on this subject?

Acceptance Criteria

Implementation Requirements

• When a change listener has been attached after a tick (queueMicrotask?) check if there is at least one error listener

Testing Requirements

• Update the eventemitter checker that asserts we always listen for errors in our tests

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc
• 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