{
  "id": 251565,
  "title": "Do you assume or confirm?",
  "url": "https://urgent.news/2026/08/07/do-you-assume-or-confirm",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-07T05:21:41.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/gerardo_leon/do-you-assume-or-confirm-57m3"
  },
  "original_language": "en",
  "account": "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.\n\nDuring 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.\n\nTo 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.\n\nOne 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.\n\nTo 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.",
  "summary": "Note: This article describes a debugging case from 2023. Some of the technologies mentioned here have since changed in relevance. In particular, Moment.js is now considered a legacy project in maintenance mode and is generally not recommended for new applications. The debugging lessons and reasoning process described here are still applicable, but the specific technical choices should be…",
  "key_points": [
    "Debugging challenge initially suspected to be race condition",
    "Debugger used question to confirm foundations of hypotheses",
    "Switched to explicit format for event timestamps to improve reliability"
  ],
  "editors_take": "Relying on assumptions rather than confirmation can lead to debugging dead ends, and verifying details through documentation and explicit checks is crucial to resolving complex technical issues reliably.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}