[DRIVERS-2477] change stream consecutive resume test should use write concern majority Created: 18/Oct/22  Updated: 27/Oct/23  Resolved: 24/Oct/22

Status: Closed
Project: Drivers
Component/s: Change Streams
Fix Version/s: None

Type: Task Priority: Unknown
Reporter: Bailey Pearson Assignee: Bailey Pearson
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split to CDRIVER-4508 change stream consecutive resume test... Closed
split to CSHARP-4371 change stream consecutive resume test... Closed
split to CXX-2602 change stream consecutive resume test... Closed
split to GODRIVER-2592 change stream consecutive resume test... Closed
split to JAVA-4785 change stream consecutive resume test... Closed
split to MOTOR-1051 change stream consecutive resume test... Closed
split to NODE-4737 change stream consecutive resume test... Closed
split to PHPLIB-1025 change stream consecutive resume test... Closed
split to PYTHON-3479 change stream consecutive resume test... Closed
split to RUBY-3161 change stream consecutive resume test... Closed
split to RUST-1513 change stream consecutive resume test... Closed
Related
related to NODE-4670 Fix failing consecutive resume change... Closed
Driver Compliance:
Key Status/Resolution FixVersion
CDRIVER-4508 Gone away
CXX-2602 Gone away
CSHARP-4371 Gone away
GODRIVER-2592 Gone away
JAVA-4785 Gone away
NODE-4737 Gone away
MOTOR-1051 Gone away
PYTHON-3479 Gone away
PHPLIB-1025 Gone away
RUBY-3161 Done
RUST-1513 Gone away
SWIFT-1663 Gone away

 Description   

Summary

The change stream consecutive resume test (here) fails intermittently in Node because the test inserts documents with write the default write concern instead of majority.

Change events are not reported by the server until they are majority committed.  The test inserts multiple documents and attempts to iterate the change stream, expecting change events.  If the documents haven't been committed by the time the test attempts to iterate the stream, no change will be reported and the test will fail.

This only impacts the consecutive resume test and does not impact users because the change event will eventually be reported.  This test specifically sets up fail commands on getMores, so that the getMore fail and the subsequent aggregate call succeeds and returns a change event in the firstBatch.  The race condition is present only because we expect the aggregate to immediately return documents in the firstBatch.

Motivation

Who is the affected end user?

Drivers engineers.

How does this affect the end user?

Flakey change stream tests.

How likely is it that this problem or use case will occur?

Unsure.  This started failing recently in Node and fails consistently now.

If the problem does occur, what are the consequences and how severe are they?

There are no consequences outside of a failing test.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Only for tests.



 Comments   
Comment by Benji Rewis (Inactive) [ 20/Oct/22 ]

https://github.com/mongodb/specifications/pull/1323

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