Loading...
Loading...
In version 5, aggregation with $out as final stage is throwing BSONObj size (16MB) error even though individual documents are much smaller. It seems to be measuring the total size of all the documents in the result set.
kyle.suarez commented on Wed, 14 Sep 2022 19:39:51 +0000: larsvancasteren@gmail.com, the fix in this ticket is present in 6.1.0-rc0; however, the team has not yet backported the fix to previous branches. We've requested backport to the v6.0, v5.0 and v4.4 versions. Please continue to watch this ticket for updates and thank you for your patience. Kyle JIRAUSER1271161 commented on Wed, 14 Sep 2022 19:35:20 +0000: MongoDB 4.4.15 When updating a $out (aggregation) on a primary node without any readPreference it runs successful. When running the same $out aggregation using the secondary node readPreference approach we get this error: BSONObj size: 16953146 (0x102AF3A) is invalid. Size must be between 0 and 16793600(16MB) First element: insert: " tmp.agg_out.55125f65 - 0ef0 - 4c1f - a7ef - dec311c99612 " For completness: https://www.mongodb.com/community/forums/t/mongodb-4-4-15-bsonobjecttoolarge-aggregation-out-update/186983 Gr, L xgen-internal-githook commented on Wed, 27 Jul 2022 23:39:07 +0000: Author: {'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'} Message: SERVER-66289 Update write size estimation logic in DocumentSourceWriter Branch: master https://github.com/mongodb/mongo/commit/7b7fe658db948e6f5a4a6c30d4590d7866c59371 mihai.andrei commented on Wed, 1 Jun 2022 18:59:28 +0000: Hi awanish@assetplus.io, Thanks for filing this ticket and reporting this issue! After doing some investigation, there does appear to be an issue with how the server handles batches of writes when running $out with secondary read preference. One thing I would like to note however, is that when investigating, I was able to reproduce the issue on 4.4 as well as 5.0. Would you be able to confirm that when you ran your aggregation with secondary read preference on 4.4, that the aggregate succeeded? Also, which shell did you use? I would like to rule out the possibility of a separate issue (that of the shell or drivers not respecting read preference). JIRAUSER1265262 commented on Tue, 24 May 2022 17:00:14 +0000: Hello, Given that this issue appears to be behaving inconsistently depending on where the query is ran from, I'm going to forward this to Driver Escalation for further investigation, given that: there is an existing driver warning in the docs for $out here: Not all driver versions support targeting of $out operations to replica set secondary nodes. Check your driver documentation to see when your driver added support for $out running on a secondary. The same query on the same data is behaving differently based on where it is going (Atlas vs local replica set) This may be affecting $merge as well, which has the same warning in the docs. Christopher JIRAUSER1269887 commented on Thu, 12 May 2022 20:26:11 +0000: Seeing this issue as well; a few details from my team's end: When running code locally on a Windows workstation pointed to Atlas cluster, aggregation succeeds. When code executes from a container in a Linux based K8s cluster pointed to the same Atlas cluster, aggregation fails with: // Anonymized method executions Error while indexing: Command aggregate failed: PlanExecutor error during aggregation :: caused by :: BSONObj size: 16813584 (0x1008E10) is invalid. Size must be between 0 and 16793600(16MB) First element: insert: "tmp.agg_out.d03d9e58-98fd-44ed-bed0-4242d6ffafce". MongoDB.Driver.MongoCommandException: Command aggregate failed: PlanExecutor error during aggregation :: caused by :: BSONObj size: 16813584 (0x1008E10) is invalid. Size must be between 0 and 16793600(16MB) First element: insert: "tmp.agg_out.d03d9e58-98fd-44ed-bed0-4242d6ffafce". at MongoDB.Driver.Core.WireProtocol.CommandUsingCommandMessageWireProtocol`1.ProcessResponse(ConnectionId connectionId, CommandMessage responseMessage) at MongoDB.Driver.Core.WireProtocol.CommandUsingCommandMessageWireProtocol`1.ExecuteAsync(IConnection connection, CancellationToken cancellationToken) at MongoDB.Driver.Core.Servers.Server.ServerChannel.ExecuteProtocolAsync[TResult](IWireProtocol`1 protocol, ICoreSession session, CancellationToken cancellationToken) at MongoDB.Driver.Core.Operations.CommandOperationBase`1.ExecuteProtocolAsync(IChannelSource channelSource, ICoreSessionHandle session, ReadPreference readPreference, CancellationToken cancellationToken) at MongoDB.Driver.Core.Operations.WriteCommandOperation`1.ExecuteAsync(IWriteBinding binding, CancellationToken cancellationToken) at MongoDB.Driver.Core.Operations.AggregateToCollectionOperation.ExecuteAsync(IWriteBinding binding, CancellationToken cancellationToken) at MongoDB.Driver.OperationExecutor.ExecuteWriteOperationAsync[TResult](IWriteBinding binding, IWriteOperation`1 operation, CancellationToken cancellationToken) at MongoDB.Driver.MongoCollectionImpl`1.ExecuteWriteOperationAsync[TResult](IClientSessionHandle session, IWriteOperation`1 operation, CancellationToken cancellationToken) at MongoDB.Driver.MongoCollectionImpl`1.AggregateAsync[TResult](IClientSessionHandle session, PipelineDefinition`2 pipeline, AggregateOptions options, CancellationToken cancellationToken) at MongoDB.Driver.MongoCollectionImpl`1.UsingImplicitSessionAsync[TResult](Func`2 funcAsync, CancellationToken cancellationToken) at **REDACTED** at **REDACTED** Setting the readPreference to primary as a workaround worked for us (kudos to @Awanish Raj). From what I've read on batchSize being set on the cursor, the total result of each batch must be less than 16MB; not just the document size. I wouldn't expect the $out stage to be done in batches, but seemed worth mentioning. JIRAUSER1269405 commented on Tue, 10 May 2022 07:53:45 +0000: The issue happens only if readPreference was "secondary". If no readPreference is given, the command succeeds. JIRAUSER1269405 commented on Tue, 10 May 2022 03:33:54 +0000: The error pops up when using Realm Triggers (In production) and MongoDB Compass Shell (In testing) to run this command so far. When I ran the same from mongosh in terminal, there was no issue and it succeeded. JIRAUSER1269405 commented on Fri, 6 May 2022 17:55:34 +0000: I have verified that the aggregation succeeds on v4.4.13, but fails on v5.0.8 and v5.3.1. JIRAUSER1269405 commented on Fri, 6 May 2022 17:35:59 +0000: I have tested it with v5.3 on Atlas. The issue remains.
Steps followed: Launch M10 cluster on Atlas and load sample dataset. In the shell, use sample_mflix db Run aggregation command: db.movies.aggregate([{$out: "movies2"}]) On version 4.4.13: The command runs successfully and movies2 collection is created. On version 5.0.8: The command fails with the error: PlanExecutor error during aggregation :: caused by :: BSONObj size: 16836845 (0x100E8ED) is invalid. Size must be between 0 and 16793600(16MB) First element: insert: "tmp.agg_out.045d5052-e014-4830-8d16-5b985ebfc46e"
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.