-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: bson-5.0.0, 5.0.1
-
Component/s: BSON
Use Case
As a js-bson Engineer
I want to ensure that EJSON.parse handles parsing dates from bigints correctly
Since BSON support was added to js-bson, EJSON.parse does not correctly deserialize
Canonical EJSON date values which were created with EJSON.stringify when useBigInt64=true.
Unknowns
- The logic (listed below) makes this kind of bug easy to run into. Should we throw
an error if we fail all of the typechecks seeing as this would be invalid EJSON by definition?
(cite spec) - The existence of this bug may also imply that there are other instances of the codebase that have bugs like this elsewhere, for example in the code to parse a timestamp from cEJSON
- Do we have a bug in how we construct EJSON using bigints?
if (value.$date != null) { const d = value.$date; const date = new Date(); if (options.legacy) { if (typeof d === 'number') date.setTime(d); else if (typeof d === 'string') date.setTime(Date.parse(d)); } else { if (typeof d === 'string') date.setTime(Date.parse(d)); else if (Long.isLong(d)) date.setTime(d.toNumber()); else if (typeof d === 'number' && options.relaxed) date.setTime(d); } return date; }
Acceptance Criteria
Implementation Requirements
- Investigate and report findings on other instances of bugs concerning the usage of bigints in the bson codebase
- Decide on whether or not we should throw error when deserializing invalid EJSON date
- Verify whether or not this happens with the other BSON types and resolve
Testing Requirements
- Write tests that check that EJSON dates are interpreted correctly when its nested $numberLong is converted to a bigint