Expected Behavior

As a... developer
I expect... alignment between the predicted/precalculated size of a BSON object and the size of a BSON object after it is written
When... invoked through the parallel `calculate_size.ts` and `serializer.ts` paths

Actual Behavior and Impact

• What is the actual behavior?
  • In the specific case of `code_with_scope`, serializer.ts and the calculate_size.ts have subtly different conditionals before emitting code_with_scope:
    • serializer.ts: codeValue.scope && typeof codeValue.scope === 'object'
    • calculate_size.ts: value.scope != null && Object.keys(value.scope).length > 0
• If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?
  • Low severity. Serialization does not rely on the calculation of calculate_size.ts and creates its own buffer

Dependencies

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

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
  • none
• Is there an opportunity for better cross-driver alignment or testing in this area?
  • no
• Is there an opportunity to improve existing documentation on this subject?
  • no

Acceptance Criteria

Implementation Requirements

• align calculate_size.ts with serializer.ts (Option A, the PR). In calculate_size.ts, replace
  value.scope != null && Object.keys(value.scope).length > 0
  with
  value.scope != null && typeof value.scope === 'object'.

Testing Requirements

• Unit tests asserting calculateObjectSize(doc) === serialize(doc).byteLength for:
  • a Code with no scope
  • a Code with an empty scope
  • a Code with a non-empty scope
• deserialize(serialize(doc)) preserves an empty scope.

Documentation Requirements

• none

Follow Up Requirements

• none