[SERVER-78084] Factor in possible error response size when building unordered bulkWrite batches Created: 14/Jun/23  Updated: 27/Oct/23  Resolved: 01/Aug/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Kaitlin Mahar Assignee: Backlog - Replication Team
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   

This ticket is being filed speculatively in the event that we end up not returning a cursor from bulkWrite. If we keep the cursor, then I believe we can just remove the TODO and close this ticket.

In the getWriteSizeFn passed to targetWriteOps for non-bulkWrite batched writes, we ensure that for unordered writes we do not build any batches that could possibly generate an error response too large to fit into a single reply.
I think we don't need this for now in the equivalent bulkWrite logic due to the cursor response allowing us to return a response of arbitrarily large size, but we could end up needing this if we change plans, so I wanted to file this ticket so we remember that.



 Comments   
Comment by Githook User [ 02/Aug/23 ]

Author:

{'name': 'Kaitlin Mahar', 'email': 'kaitlin.mahar@mongodb.com', 'username': 'kmahar'}

Message: SERVER-78084 Remove unneeded TODO
Branch: minh.luu-no_compile_sys-perf
https://github.com/mongodb/mongo/commit/6ed73bfd9c6fe5f67ea2e90b81901a56ece0c116

Comment by Kaitlin Mahar [ 01/Aug/23 ]

This ticket was only relevant if we ended up not returning a cursor from bulkWrite, but we decided against that change. So the commit above is just removing the TODO. 

Comment by Githook User [ 01/Aug/23 ]

Author:

{'name': 'Kaitlin Mahar', 'email': 'kaitlin.mahar@mongodb.com', 'username': 'kmahar'}

Message: SERVER-78084 Remove unneeded TODO
Branch: master
https://github.com/mongodb/mongo/commit/6ed73bfd9c6fe5f67ea2e90b81901a56ece0c116

Generated at Thu Feb 08 06:37:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.