[spokodev]

Description

Binary.toExtendedJSON() base64-encodes the entire backing buffer instead of the written region [0, position), corrupting Extended JSON output for any Binary built incrementally with the documented put() / write() API.

new Binary() allocates a 256-byte buffer and tracks how much is used in position. Every other accessor (value(), toJSON(), toString(), inspect()) slices to position, but toExtendedJSON() encoded this.buffer in full. So a Binary with 3 bytes written serialized to a 344-character base64 string of mostly zero padding instead of the 4 characters for those 3 bytes.

const bin = new BSON.Binary();
bin.put(1); bin.put(2); bin.put(3);
EJSON.stringify(bin);            // $binary.base64 was 'AQIDAAAA...' (256 bytes) instead of 'AQID'
EJSON.parse(EJSON.stringify(bin)).value(); // [1,2,3,0,0,...] instead of [1,2,3]

The BSON path already slices correctly, so BSON and Extended JSON representations of the same object disagreed. This violates MongoDB Extended JSON v2, where $binary.base64 is the payload, not the internal allocation.

Fix

-    const base64String = ByteUtils.toBase64(this.buffer);
+    const base64String = ByteUtils.toBase64(this.buffer.subarray(0, this.position));

Matches what value() / toJSON() / toString() already do.

Test

Added a toExtendedJSON() case to test/node/binary.test.ts (mirrors the existing toString / toJSON "should respect position" tests). It fails before the change (full-buffer base64) and passes after. The full node suite stays green.

[PavelSafronov]

Thank you for taking the time to create this PR and providing so much detail. This PR will be tracked in NODE-7642 and the team will prioritize it in the next triage session.

[spokodev]

@tadjik1, #908 was approved on 5 October; here is where its two siblings stand.

This one is now rebased onto main (it was 16 commits behind). npm test passes, the two new tests run, and with the src/binary.ts change reverted, "should respect position when converting to Extended JSON" fails.

#911 (NODE-7661) is already current with main and behaves the same way: with its fix reverted, "matches the serialized byte length" fails.

Both will need evergreen authorized on their current heads.