The conformance suite now checks that your store returns every digit of a double

Version 4.1.0 of the core event sourcing package adds one conformance case to its testing subpath, called payload-number-precision. It checks that a store hands back the doubles in a payload with every significant digit intact. The built-in stores already pass it. If you run the suites against your own event store or snapshot store, this release changes what they check.

Slide text

The conformance suite now checks that your store returns every digit of a double

0.1 + 0.2, as JavaScript stores it, with its 17th significant digit

0. 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4

@ocoda/event-sourcing 4.1.0

Until now, the closest check was payload-json-fidelity, and it only holds short decimals. So take a payload with 0.1 plus 0.2 in it. JavaScript stores that as a double with a 4 in the seventeenth significant digit. A store that parses or prints JSON numbers with only 15 digits gives back plain 0.3. The old case passed a store like that. The new case fails it.

Here's what the new case writes and reads back. That same sum, and its negative. The double just below 1. 2 to the power of minus 44. A 17-digit number a little over 123 million, and the largest double JavaScript can hold. Each one comes back unchanged through JSON, and each one changes when it's rounded to 15 digits.

({
  sum: 0.1 + 0.2,
  negativeSum: -(0.1 + 0.2),
  belowOne: 1 - Number.EPSILON / 2,
  small: 2 ** -44,
  large: 123_456_789.123_456_79,
  max: Number.MAX_VALUE,
})

The case runs in both suites. On the event store, the doubles have to come back unchanged from getEvent, getEvents, getEnvelope and getEnvelopes. On the snapshot store, from getSnapshot, getSnapshots, getLastSnapshot, getLastSnapshots and getEnvelope. Every built-in store passes it. The core package also keeps a deliberately lossy test store that rounds to 15 digits, to prove the case catches one.

A custom store that runs the suites may now fail this case. The fix is in how the store keeps numbers, and how it prints them. Store the payload as JSON text, or as binary doubles. And when the store prints a number, use the shortest form that reads back as the same double. That's what JSON.stringify already does.

Until the store is fixed, skip the case in the suite's skip option, and write down why. Once you think it's fixed, set CONFORMANCE_RUN_SKIPPED to true. The suites then run the skipped cases, so you can check whether the skip is still needed.

describeEventStoreConformance(
  'FooEventStore',
  async (context) => { … },
  {
    skip: {
      'payload-number-precision': '<why>',
    },
  },
);

To upgrade, install the 4.x line of the core package. The change lives in the testing subpath, so it only shows up where your tests call the conformance suites. If you maintain your own store, run its suites first, and fix the store or skip the case with a reason. The PostgreSQL, MariaDB and MongoDB packages published their own 4.1.0 notes. For the core, the conformance suite now checks that your store returns every digit of a double.