GODRIVER-2388 Improved Bulk Write API. #1884

qingyang-hu · 2024-11-05T18:59:31Z

GODRIVER-2388
GODRIVER-3348
GODRIVER-3349
GODRIVER-3364

GODRIVER-3421 (added in fc91428)

Summary

Improved Bulk Write API.

sort option will be added in GODRIVER-3285
handshakeError.json has not been added (blocked by GODRIVER-2191)

Background & Motivation

Refactor the (Operation).createWireMessage() to support the bulk write batching.

mongodb-drivers-pr-bot · 2024-11-05T19:02:03Z

API Change Report

./v2/mongo

compatible changes

(*Client).BulkWrite: added
ClientBulkWriteDeleteResult: added
ClientBulkWriteException: added
ClientBulkWriteInsertResult: added
ClientBulkWriteResult: added
ClientBulkWriteUpdateResult: added
ClientDeleteManyModel: added
ClientDeleteOneModel: added
ClientInsertOneModel: added
ClientReplaceOneModel: added
ClientUpdateManyModel: added
ClientUpdateOneModel: added
ClientWriteModels: added
NewClientDeleteManyModel: added
NewClientDeleteOneModel: added
NewClientInsertOneModel: added
NewClientReplaceOneModel: added
NewClientUpdateManyModel: added
NewClientUpdateOneModel: added

./v2/mongo/options

compatible changes

ClientBulkWrite: added
ClientBulkWriteOptions: added
ClientBulkWriteOptionsBuilder: added

./v2/x/mongo/driver

incompatible changes

(*Batches).AdvanceBatch: removed
(*Batches).ClearBatch: removed
(*Batches).Valid: removed
Batches.Current: removed
##NewCursorResponse: changed from func(ResponseInfo) (CursorResponse, error) to func(./v2/x/bsonx/bsoncore.Document, ResponseInfo) (CursorResponse, error)
Operation.Batches: changed from *Batches to OperationBatches
##Operation.ProcessResponseFn: changed from func(ResponseInfo) error to func(context.Context, ./v2/x/bsonx/bsoncore.Document, ResponseInfo) error
ResponseInfo.ServerResponse: removed

compatible changes

(*Batches).AdvanceBatches: added
(*Batches).AppendBatchArray: added
(*Batches).AppendBatchSequence: added
(*Batches).IsOrdered: added
(*Batches).Size: added
ExtractCursorDocument: added
OperationBatches: added
ResponseInfo.Error: added

./v2/x/mongo/driver/session

incompatible changes

Client.RetryRead: removed
Client.RetryWrite: removed

./v2/x/mongo/driver/wiremessage

compatible changes

DocumentSequenceToArray: added

qingyang-hu · 2024-11-05T20:17:37Z

internal/integration/client_side_encryption_test.go

@@ -398,7 +398,7 @@ func TestClientSideEncryptionCustomCrypt(t *testing.T) {
 			"expected 0 calls to DecryptExplicit, got %v", cc.numDecryptExplicitCalls)
 		assert.Equal(mt, cc.numCloseCalls, 0,
 			"expected 0 calls to Close, got %v", cc.numCloseCalls)
-		assert.Equal(mt, cc.numBypassAutoEncryptionCalls, 2,
+		assert.Equal(mt, cc.numBypassAutoEncryptionCalls, 1,


We only call it once after the operation.go refactoring.

qingyang-hu · 2024-11-05T20:18:06Z

mongo/errors.go

+	// A top-level error that occurred when attempting to communicate with the server
+	// or execute the bulk write. This value may not be populated if the exception was
+	// thrown due to errors occurring on individual writes.
+	TopLevelError *WriteError


Cannot use Error as a field name because of the conflict with the conventional method name.

Optional: Consider the more conventional Err or WriteError.

mongo/errors.go

mongo/client.go

mongo/client_bulk_write_models.go

prestonvasquez · 2024-11-11T21:30:03Z

mongo/client_bulk_write_models.go

+}
+type clientWriteModel struct {
+	namespace string
+	model     interface{}


Should we add stronger type constraints to this?

type clientBulkWriteModel interface { ClientInsertOneModel // etc. } type clientWriteModel struct { namespace string model clientBulkWriteModel }

I don't think we need an additional abstraction for an un-exported struct.

mongo/results.go

prestonvasquez · 2024-11-11T22:48:31Z

mongo/errors.go

+}
+
+// Error implements the error interface.
+func (bwe ClientBulkWriteException) Error() string {


This function doesn't return an error if the write is unacknowledged. The specifications required that users be able to discern whether a BulkWriteResult contains acknowledged results. Either return an error indicating an unacknowledged result, or update ClientBulkWriteResult in the spirit of GODRIVER-2821.

You can test this with the following:

package main import ( "context" "go.mongodb.org/mongo-driver/v2/bson" "go.mongodb.org/mongo-driver/v2/mongo" "go.mongodb.org/mongo-driver/v2/mongo/options" "go.mongodb.org/mongo-driver/v2/mongo/writeconcern" ) func main() { client, err := mongo.Connect() if err != nil { panic(err) } defer func() { _ = client.Disconnect(context.Background()) }() pairs := &mongo.ClientWriteModels{} insertOneModel := mongo.NewClientInsertOneModel().SetDocument(bson.D{{"x", 1}}) opts := options.ClientBulkWrite().SetWriteConcern(writeconcern.Unacknowledged()).SetOrdered(false) pairs = pairs.AppendInsertOne("db", "k", insertOneModel) _, err = client.BulkWrite(context.Background(), pairs, opts) // Should not panic if err != nil { panic(err) } }

Is there a unified spec test that covers this case? If not we should add one / add an integration test.

Test case added at d10eff2#diff-2b04421639d947fd71e799c04cb9df94f58b9be8967998b3e4810c711e9c3671R758-R775

qingyang-hu · 2024-11-15T21:03:29Z

mongo/bulk_write.go

+		if filter == nil {
+			return nil, fmt.Errorf("%w: filter is required", err)
+		}


update the error message when the filter is not given.

Is there a reason to nest this nil filter check in this error handling block? Can we move this check to the beginning of marshal?

Optional: Consider a clearer error message, like

delete filter cannot be nil

qingyang-hu · 2024-11-15T21:03:39Z

mongo/bulk_write.go

+		if doc.filter == nil {
+			return nil, fmt.Errorf("%w: filter is required", err)
+		}


update the error message when the filter is not given.

Is there a reason to nest this nil filter check in this error handling block? Can we move this check to the beginning of marshal?

Optional: Consider a clearer error message, like

update filter cannot be nil

prestonvasquez

@qingyang-hu There are still outstanding issues from the previous review.

prestonvasquez · 2024-11-18T18:28:26Z

mongo/results.go

@@ -13,6 +13,55 @@ import (
 	"go.mongodb.org/mongo-driver/v2/x/mongo/driver/operation"
 )

+// ClientBulkWriteResult is the result type returned by a client-level BulkWrite operation.
+type ClientBulkWriteResult struct {


The specifications say that "Users MUST be able to discern whether a [result] contains verbose results without inspecting the value provided for verboseResults in [options]". Does this mean we should add a boolean value ClientBulkWriteResult: HasVerboseResults?

The initial thought was to leave results maps as nil when verboseResults is false. However, I think you are right that an additional HasVerboseResults field is more obvious.

I see, either solution sounds good to me.

prestonvasquez · 2024-11-18T21:24:53Z

mongo/client_bulk_write_test.go

+			},
+		}
+		var n int
+		n, _, err = batches.AppendBatchSequence(nil, 4, 16_000, 16_000)


What is the significance of 16_000 here?

It is just a number big enough not to cut the document, so only the maxCount regulates the output. Will add a comment there.

prestonvasquez · 2024-11-18T21:43:59Z

mongo/client_bulk_write.go

+			var idx int32
+			dst = wiremessage.AppendMsgSectionType(dst, wiremessage.DocumentSequence)
+			idx, dst = bsoncore.ReserveLength(dst)
+			dst = append(dst, identifier...)


From the specifications:

The first entry in each document has the name of the operation as its key and the index ini the nsInfo array of the namespace on which the operation should be performed as its value

When I do command monitoring for client bulk write with multiple pairs, I get the following:

2024/11/18 14:39:47 started: &{Command:{"bulkWrite": {"$numberInt":"1"},"errorsOnly": false,"ordered": true,"lsid": {"id": {"$binary":{"base64":"XTDtLVGhTx6MEIcFDhf0qw==","subType":"04"}}},"txnNumber": {"$numberLong":"1"},"$clusterTime": {"clusterTime": {"$timestamp":{"t":1731965987,"i":1}},"signature": {"hash": {"$binary":{"base64":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","subType":"00"}},"keyId": {"$numberLong":"0"}}},"$db": "admin","ops": [{"insert": {"$numberInt":"0"},"document": {"_id": {"$oid":"673bb423a86efe4126c4c585"},"x": {"$numberInt":"1"}}},{"insert": {"$numberInt":"0"},"document": {"_id": {"$oid":"673bb423a86efe4126c4c586"},"x": {"$numberInt":"2"}}}],"nsInfo": [{"ns": "db.coll"}]} DatabaseName:admin CommandName:bulkWrite RequestID:1 ConnectionID:localhost:27017[-4] ServerConnectionID:0x14000390250 ServiceID:<nil>}

Where the index value for each document in the sequence is {"$numberInt":"0"}. Shouldn't this be {"$numberInt":"0"}, then {"$numberInt":"1"}, etc?

The same thing occurs with the other client bulk write operations.

Did you mean the Int32 value of the operation name such as "insert", "update", or "delete"?

... "ops":[ { "insert":{ "$numberInt":"0" }, ...

It is "the index in the nsInfo array of the namespace on which the operation should be performed as its value".

The specs also require:

When constructing the nsInfo array for a bulkWrite batch, drivers MUST only include the namespaces that are referenced in the ops array for that batch.

and:

Drivers MUST NOT include duplicate namespaces in this list.

Therefore, if both operations perform on the same namespace, the nsInfo array should contain only one item, and both operation indices are 0, pointing to "db.coll".

I see, thanks for the explanation!

prestonvasquez · 2024-12-03T23:36:40Z

x/mongo/driver/batches.go

+// AppendBatchSequence appends dst with document sequence of batches as long as the limits of max count, max
+// document size, or total size allows. It returns the number of batches appended, the new appended slice, and
+// any error raised. It returns the origenal input slice if nothing can be appends within the limits.
+func (b *Batches) AppendBatchSequence(dst []byte, maxCount, maxDocSize, _ int) (int, []byte, error) {


Does maxMessageSizeBytes not apply when not using bulk write? For example, when using collection.Insert would we batch up to 48mb or 16mb? If I understand the documentation correctly, the batch has a limit of 48mb and individual documents in the batch have a limit of 16mb. Right now it appears we are limiting the entire batch to 16mb. The clientBulkWrite API does what I would expect.

The logic derives from the original *Batches.AdvanceBatch(), which takes maxDocumentSize as maxMessageSizeBytes. A test case covers the logic here.

@matthewdale, do you know any history of the logic?

I've updated the logic in fc91428.

Should we open a ticket for this to avoid adding more complexity to this PR?

IMO, it doesn't make sense to review incorrect logic since we've already refactored that block. Moreover, fc91428 removed the maxBsonObjectSize requirement from the client-level bulk write to simplify the PR.

However, I'm open to reverting and only keeping what is more relevant.

IIU the updated solution correctly it is now possible to put a single document over the 16mb limit on the wire message, relying on the server to validate the document size. From what I can tell, this is spec-compliant. But do we want to make data-heavy round trips that we know are going to fail?

Correct, both the client-level bulk write and legacy bulk write rely on the server to check the document size limit in fc91428.

But I agree the validation on the server side is inefficient. Pre-validating the size on the driver side is not a breach of the spec because it is not prohibited, either, especially for performance reasons. So I will commit another change to return driver side errors.

FWIW IMO we can defer that work.

prestonvasquez · 2024-12-03T23:38:51Z

x/mongo/driver/operation.go

@@ -268,7 +271,13 @@ type Operation struct {
 	// has more documents than can fit in a single command. This should only be specified for
 	// commands that are batch compatible. For more information, please refer to the definition of
 	// Batches.
-	Batches *Batches
+	Batches interface {


Suggest internalizing this interface so that we can create a compile check for mongo.modelBatches and x/mongo.Batches.

prestonvasquez · 2024-12-03T23:47:04Z

mongo/client_bulk_write.go

+	return len(mb.models) - mb.offset
+}
+
+func (mb *modelBatches) AppendBatchSequence(dst []byte, maxCount, maxDocSize, totalSize int) (int, []byte, error) {


Do we have test coverage for this in the following two cases:

One doc exceeds maxBsonObjectSize, I would expect an error.

Multiple documents < maxBsonObjectSize together exceed maxMessageSizeBytes. I would expect n > 1.

Here is a helpful gist I used: https://gist.github.com/prestonvasquez/40daa306abc5a21147235d2ea982d841

I've involved GODRIVER-3421 in fc91428, which removes the BSON document size validation requirement. So the first case is no longer needed. The second case is added in both client_bulk_write_test.go and client_test.go.

qingyang-hu

Addressing GODRIVER-3421, the BSON document size validation requirement for the client bulk write operation has been removed in fc91428. Both client bulk writes and legacy bulk writes rely on the server to check the document size limit now.

prestonvasquez · 2024-12-06T21:56:20Z

internal/integration/crud_prose_test.go

+	mtOpts := mtest.NewOptions().MinServerVersion("8.0").AtlasDataLake(false).ClientType(mtest.Pinned)
+	mt := mtest.New(t, mtOpts)
+
+	mt.Run("bulkWrite batch splits a writeModels input with greater than maxWriteBatchSize operations", func(mt *mtest.T) {


Can we label the prose tests? I.e., this should be

3. bulkWrite batch splits a writeModels input with greater than maxWriteBatchSize operations

prestonvasquez · 2024-12-06T22:26:47Z

internal/integration/csot_prose_test.go

+		cli, err := mongo.Connect(cliOptions)
+		require.NoError(mt, err, "Connect error: %v", err)
+		_, err = cli.BulkWrite(context.Background(), models)
+		assert.ErrorContains(mt, err, "context deadline exceeded", "expected a timeout error, got: %v", err)


Suggest using asser.ErrorIs and the package error context.DeadlineExceeded:

Suggested change

assert.ErrorContains(mt, err, "context deadline exceeded", "expected a timeout error, got: %v", err)

assert.ErrorIs(mt, err, context.DeadlineExceeded, "expected a timeout error, got: %v", err)

prestonvasquez · 2024-12-06T22:30:54Z

internal/integration/unified/client_operation_execution.go

+	if res == nil || !res.Acknowledged {
+		return newDocumentResult(emptyCoreDocument, err), nil
+	}
+	rawBuilder := bsoncore.NewDocumentBuilder().


Why do we use bsoncore? Can we just populate mongo.ClientBulkWriteResult and encode?

The encoder encodes all fields in lowercase by default. An alternative may be a struct with tags. The current resolution follows the pattern in executeCreateChangeStream and executeListDatabases.

prestonvasquez · 2024-12-06T23:22:48Z

internal/integration/unified/client_operation_execution.go

+		model.ArrayFilters = v.ArrayFilters
+	}
+	return v.Namespace, model, nil
+


Suggested change

prestonvasquez · 2024-12-06T23:24:11Z

internal/integration/unified/client_operation_execution.go

+		Hint         *bson.RawValue
+		Upsert       *bool
+	}
+	err := bson.Unmarshal(value, &v)


Why do we need to define the extra fields? Can we unmarshal into an embedded mongo.ClientUpdateOneModel?

var v struct { Namespace string mongo.ClientUpdateOneModel }

The spec tests put bulk write fields in parallel with the namespace. We cannot embed mongo.ClientUpdateOneModel without a nested level.

matthewdale · 2024-12-18T02:27:42Z

internal/integration/client_side_encryption_test.go

@@ -394,7 +394,7 @@ func TestClientSideEncryptionCustomCrypt(t *testing.T) {
 			"expected 0 calls to DecryptExplicit, got %v", cc.numDecryptExplicitCalls)
 		assert.Equal(mt, cc.numCloseCalls, 0,
 			"expected 0 calls to Close, got %v", cc.numCloseCalls)
-		assert.Equal(mt, cc.numBypassAutoEncryptionCalls, 2,
+		assert.Equal(mt, cc.numBypassAutoEncryptionCalls, 1,
 			"expected 2 calls to BypassAutoEncryption, got %v", cc.numBypassAutoEncryptionCalls)


Optional: Update error message to match updated assertion.

Suggested change

"expected 2 calls to BypassAutoEncryption, got %v", cc.numBypassAutoEncryptionCalls)

"expected 1 call to BypassAutoEncryption, got %v", cc.numBypassAutoEncryptionCalls)

matthewdale · 2024-12-18T02:29:23Z

x/mongo/driver/wiremessage/wiremessage.go

@@ -422,6 +423,39 @@ func ReadMsgSectionRawDocumentSequence(src []byte) (identifier string, data []by
 	return identifier, rem, rest, true
 }

+// DocumentSequenceToArray converts a document sequence in byte slice to an array.
+func DocumentSequenceToArray(src []byte) (dst, rem []byte, ok bool) {


Optional: This function is only used in operation.go, consider moving it there.

matthewdale · 2024-12-18T04:07:57Z

mongo/client_bulk_write_models.go

+}
+
+// AppendUpdateOne appends ClientUpdateOneModels.
+func (m *ClientWriteModels) AppendUpdateOne(database, collection string, models ...*ClientUpdateOneModel) *ClientWriteModels {


Is there a reason to use per-model-type setters instead of the unexported interface pattern that the existing bulk write models use?

For example:

type ClientWriteModel interface { clientWriteModel() } type ClientUpdateOneModel struct { ... } func (ClientUpdateOneModel) clientWriteModel() {} func (m *ClientWriteModels) Append(database, collection string, models ...ClientWriteModel) *ClientWriteModels { m.models = append(...) return m }

I've revised the (*Client).BulkWrite() signature to accept the Namespace-WriteModel pairs in a slice to align with the legacy bulk write API.

matthewdale · 2024-12-20T04:08:11Z

mongo/client_test.go

@@ -514,4 +515,39 @@ func TestClient(t *testing.T) {
 		errmsg := `invalid value "-1s" for "Timeout": value must be positive`
 		assert.Equal(t, errmsg, err.Error(), "expected error %v, got %v", errmsg, err.Error())
 	})
+	t.Run("bulkWrite with large messages", func(t *testing.T) {


Any test that connects to a running MongoDB server should ideally use mtest. Since we can't use mtest in the mongo package, this test case should be moved to internal/integration/client_test.go.

matthewdale · 2024-12-20T21:58:27Z

testdata/transactions/unified/mongos-pin-auto-tests.py

Is this file required, or can it be omitted?

matthewdale · 2024-12-20T22:06:29Z

internal/integration/client_test.go

@@ -718,6 +719,95 @@ func TestClient(t *testing.T) {
 			})
 		}
 	})
+	mtBulkWriteOpts := mtest.NewOptions().MinServerVersion("8.0").AtlasDataLake(false).ClientType(mtest.Pinned)
+	mt.RunOpts("bulk write with nil filter", mtBulkWriteOpts, func(mt *mtest.T) {


Optional: We should separate test functions as much as possible because it makes the code easier to read and the test easier to run. Consider splitting these two BulkWrite subtests into its own test func.

E.g.

func TestClient_BulkWrite(t *testing.T) { // ...

matthewdale · 2024-12-24T03:42:36Z

mongo/client_bulk_write.go

+type clientInsertDoc struct {
+	namespace int
+	document  interface{}
+}
+
+func (d *clientInsertDoc) marshal(bsonOpts *options.BSONOptions, registry *bson.Registry) (interface{}, bsoncore.Document, error) {


Is it possible to omit these duplicated types and define the marshal functions on the exported type instead? Do the duplicated types serve any additional purpose?

matthewdale · 2024-12-24T03:45:01Z

mongo/client_bulk_write.go

+	if err != nil {
+		if d.filter == nil {
+			return nil, fmt.Errorf("%w: filter is required", err)
+		}


Is there a reason to nest this nil filter check in this error handling block? Can we move this check to the beginning of marshal?

Optional: Consider a clearer error message, like

update filter cannot be nil

matthewdale · 2024-12-24T03:47:53Z

mongo/client_bulk_write.go

+	if err != nil {
+		if d.filter == nil {
+			return nil, fmt.Errorf("%w: filter is required", err)
+		}


Is there a reason to nest this nil filter check in this error handling block? Can we move this check to the beginning of marshal?

Optional: Consider a clearer error message, like

delete filter cannot be nil

matthewdale · 2024-12-24T03:48:15Z

mongo/bulk_write.go

+		if doc.filter == nil {
+			return nil, fmt.Errorf("%w: filter is required", err)
+		}


Is there a reason to nest this nil filter check in this error handling block? Can we move this check to the beginning of marshal?

Optional: Consider a clearer error message, like

update filter cannot be nil

matthewdale · 2024-12-24T03:49:58Z

mongo/bulk_write.go

+		if filter == nil {
+			return nil, fmt.Errorf("%w: filter is required", err)
+		}


Is there a reason to nest this nil filter check in this error handling block? Can we move this check to the beginning of marshal?

Optional: Consider a clearer error message, like

delete filter cannot be nil

matthewdale · 2024-12-24T03:52:25Z

mongo/errors.go

+	// A top-level error that occurred when attempting to communicate with the server
+	// or execute the bulk write. This value may not be populated if the exception was
+	// thrown due to errors occurring on individual writes.
+	TopLevelError *WriteError


Optional: Consider the more conventional Err or WriteError.

qingyang-hu added 2 commits November 4, 2024 16:55

GODRIVER-2388 Improved Bulk Write API.

1309416

GODRIVER-2388 implementation

4d88edf

mongodb-drivers-pr-bot bot added the priority-3-low Low Priority PR for Review label Nov 5, 2024

qingyang-hu commented Nov 5, 2024

View reviewed changes

qingyang-hu marked this pull request as ready for review November 5, 2024 20:18

qingyang-hu requested review from matthewdale and prestonvasquez November 5, 2024 20:18

qingyang-hu added priority-2-medium Medium Priority PR for Review and removed priority-3-low Low Priority PR for Review labels Nov 5, 2024

qingyang-hu mentioned this pull request Nov 5, 2024

GODRIVER-3285 Allow update to supply sort option. #1797

Merged

prestonvasquez requested changes Nov 11, 2024

View reviewed changes

qingyang-hu commented Nov 15, 2024

View reviewed changes

qingyang-hu force-pushed the godriver2388v2 branch 4 times, most recently from 4bc724e to dbd44c9 Compare November 15, 2024 23:14

updates

d10eff2

qingyang-hu force-pushed the godriver2388v2 branch from dbd44c9 to d10eff2 Compare November 15, 2024 23:31

qingyang-hu requested a review from prestonvasquez November 16, 2024 00:14

prestonvasquez requested changes Nov 18, 2024

View reviewed changes

add HasVerboseResults in ClientBulkWriteResult

3489ac8

qingyang-hu force-pushed the godriver2388v2 branch from dd218ab to 3489ac8 Compare November 27, 2024 19:19

add comments

acca80b

alcaeus requested a review from prestonvasquez December 3, 2024 16:21

prestonvasquez requested changes Dec 3, 2024

View reviewed changes

qingyang-hu force-pushed the godriver2388v2 branch 2 times, most recently from 9958e3f to 82df60a Compare December 4, 2024 20:14

qingyang-hu force-pushed the godriver2388v2 branch from 82df60a to 1f763d0 Compare December 4, 2024 20:42

GODRIVER-3421 Remove the BSON document size validation.

fc91428

qingyang-hu force-pushed the godriver2388v2 branch from 1f763d0 to fc91428 Compare December 4, 2024 22:41

fix tests

ce3ed92

qingyang-hu force-pushed the godriver2388v2 branch from 8bd512c to ce3ed92 Compare December 4, 2024 23:23

qingyang-hu commented Dec 6, 2024

View reviewed changes

Merge branch 'master' into godriver2388v2

4f9c841

prestonvasquez requested changes Dec 6, 2024

View reviewed changes

matthewdale reviewed Dec 18, 2024

View reviewed changes

qingyang-hu force-pushed the godriver2388v2 branch from bca2564 to 91dabcd Compare December 18, 2024 22:34

Align client bulk write API with legacy bulk write.

89947bd

qingyang-hu force-pushed the godriver2388v2 branch from 91dabcd to 89947bd Compare December 18, 2024 23:18

qingyang-hu requested review from matthewdale and prestonvasquez December 19, 2024 14:09

prestonvasquez approved these changes Dec 21, 2024

View reviewed changes

matthewdale reviewed Dec 24, 2024

View reviewed changes

	assert.ErrorContains(mt, err, "context deadline exceeded", "expected a timeout error, got: %v", err)
	assert.ErrorIs(mt, err, context.DeadlineExceeded, "expected a timeout error, got: %v", err)

	"expected 2 calls to BypassAutoEncryption, got %v", cc.numBypassAutoEncryptionCalls)
	"expected 1 call to BypassAutoEncryption, got %v", cc.numBypassAutoEncryptionCalls)

GODRIVER-2388 Improved Bulk Write API. #1884

Are you sure you want to change the base?

GODRIVER-2388 Improved Bulk Write API. #1884

Conversation

qingyang-hu commented Nov 5, 2024 • edited Loading

Summary

Background & Motivation

mongodb-drivers-pr-bot bot commented Nov 5, 2024 • edited Loading

API Change Report

./v2/mongo

compatible changes

./v2/mongo/options

compatible changes

./v2/x/mongo/driver

incompatible changes

compatible changes

./v2/x/mongo/driver/session

incompatible changes

./v2/x/mongo/driver/wiremessage

compatible changes

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prestonvasquez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qingyang-hu Nov 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qingyang-hu Nov 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prestonvasquez Dec 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prestonvasquez Dec 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prestonvasquez Dec 3, 2024 • edited Loading

Choose a reason for hiding this comment

qingyang-hu Dec 4, 2024 • edited Loading

Choose a reason for hiding this comment

qingyang-hu left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qingyang-hu commented Nov 5, 2024 •

edited

Loading

mongodb-drivers-pr-bot bot commented Nov 5, 2024 •

edited

Loading

qingyang-hu Nov 18, 2024 •

edited

Loading

qingyang-hu Nov 18, 2024 •

edited

Loading

prestonvasquez Dec 3, 2024 •

edited

Loading

prestonvasquez Dec 5, 2024 •

edited

Loading

prestonvasquez Dec 3, 2024 •

edited

Loading

qingyang-hu Dec 4, 2024 •

edited

Loading

qingyang-hu left a comment •

edited

Loading