Use Case

As a driver engineer and user,
I want RTT pinging to work properly,
So that the driver has a reliable and accurate RTT measurement.

User Experience

• Likely minimal. In practice, it is likely that if the RTT pinger encounters errors, the monitoring connection would as well. If the monitoring connection errors, the server is marked unknown and the monitor will be reset, which resets the RTT pinger.

Dependencies

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

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
• 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

• After encountering an error, either establishing the RTT pinging connection or while executing a `hello`, ensure that the RTT pinger continues to RTT ping.
• (optional) we can take this opportunity to refactor the RTT pinger and its monitoring loop to use async-await and a for-await loop instead of `setTimeout`.

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
• 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