Do you assume or confirm?

Two systems communicate through event-based messaging, with the originator system sending events in a specific order. However, the receiving system sometimes fails to update its UI in the same order as the events are received. This led to a debugging challenge initially suspected to be a race condition due to multiple events being emitted within the same second.

During the debugging process, the originator system was a candidate for change due to a recent optimization that reduced event production time. However, the reasoning behind this recommendation relied heavily on assumptions and familiarity with the domain. The debugger realized that trusting System 1, or the automatic, emotional, and quick-to-respond mode of thinking, could lead to misleading conclusions and unreliable decisions.

To avoid falling into the trap of assuming without confirmation, the debugger used a simple question: "For the next hypothesis I'm about to accept, have I confirmed its foundations, or am I assuming them?" This simple check helped prevent getting trapped in debugging dead ends.

One problem was identified in the receiver's event interpreter, which used Moment.js to compare event timestamps. Moment.js, being a legacy JavaScript project, inherits limitations from the JavaScript Date object, which stores time with millisecond precision. Since Moment.js relies on JavaScript dates, it cannot preserve fractional seconds beyond three digits.

To resolve this issue, the debugger switched to using the original timestamp strings and added additional fractional-second digits as a tiebreaker when two events appeared equal at millisecond precision. However, another issue arose where some reported cases still produced unexpected tiebreaker values. This was due to the fractional-second representation not always being identical, even when events were equal at millisecond precision.

The debugger then switched to a regular expression to identify the relevant fractional-second portion more explicitly. This improved reliability but some additional reports still came in. These issues were not related to the comparison logic itself but rather to timestamps containing fewer fractional-second digits than expected. The affected timestamps contained trailing zeroes that were not preserved due to a modification in the serialization layer.

The serialization layer was using Newtonsoft.Json, which could omit trailing fractional-second zeroes depending on the configured format. After switching to an explicit and validated format using an IsoDateTimeConverter, the event timestamp comparison became considerably more reliable.

The key lesson from this debugging case is to always read the documentation and verify assumptions before proposing a workaround. It is essential to get to the root of the problem and not mistake an assumption for a confirmed constraint. Additionally, when working with structured strings, it is crucial to identify the exact format expected instead of relying on positional assumptions such as arbitrary slicing.