Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-6076

Add reasons to SDAM events

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: None
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?

      Use Case

      As a user of the driver,
      I want driver events that can be emitted in multiple places to contain information about the cause of the event,
      So that I can determine the cause of a given event without cross referencing other driver events and state when debugging.

       

      Some driver non-error events can be emitted from multiple locations.  `TopologyDescriptionChangedEvent`s, for example can be emitted when the client connects, as a response to a server heartbeat event, or as a response to srv polling events.  There is currently no information on the event that indicates the cause or location in the driver this event was emitted from.  As an example, if the topology changed event had a field `reason` that could be "topology connected | heartbeat processed with new servers | srv polling detected new servers", it would be much easier to track down the cause of certain events when debugging using driver events.

      Error events could also benefit from more information, but they already contain some clue as to why there were created (they contain errors with stacktraces).  

      User Impact

      • What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?

      Dependencies

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

      Unknowns

      • questions that need to be answered to determine implementation

      Acceptance Criteria

      Implementation Requirements

      • functional reqs, potential snafus to avoid, performance targets, etc

      Testing Requirements

      • unit test, spec test sync, etc

      Documentation Requirements

      • DOCSP ticket, API docs, etc

      Follow Up Requirements

      • additional tickets to file, required releases, etc

            Assignee:
            Unassigned Unassigned
            Reporter:
            bailey.pearson@mongodb.com Bailey Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: