Priority: Major - P3
Affects Version/s: 3.1.0
Fix Version/s: None
I see an inconsistency in cursor and stream handling revolving around the Cursor.map() function that becomes evident when dealing with asyncIterator within Readable streams.
Something odd is happening with content available in the document when iterating this way, and it seems to manifest consistently with the Array.prototype.reduce() not being recognized as present despite the data being consistently shown as an array. The following listing was used to test:
The issue I consistently see is that the Cursor.map() using reduce() will consistently fail when applied in a for..await..of style iterator. The error in fact implies that the "array" is not actually there:
If you try to "force" the casting via Array.from() then any call to reduce() treats the array as being empty. However as the listing demonstrates, the Array.prototype.map() function does not have the same issue.
The other slight oddity is that with a transform option on the stream instead of using Cursor.map() then the for..await..of style using Symbol.asyncIterator on the Readable stream works just as expected. That transform however is notably ignored by calling methods directly such as Cursor.next() or any derivative that makes that call, and yet having next() is required for the Symbol.asyncIterator compliance.
Placing both the Cursor.map() and Cursor.stream() options including a transform function works as expected with the direct Cursor.next() which essentially ignores the transform, however it comes across the same problem when calling reduce() on the stream.
It's unclear where exactly the problem is occurring apart from something very inconsistent is happening with Cursor.map()
And the expected output from the supported options is as shown. Noting this will only output this way by not using Cursor.map() with the Array.reduce() on the call with for..await..of, but the last output shows Array.map() within Cursor.map() works as expected on the final output always: