[SERVER-81295] Cannot resume V2 changeStream pipelines with V1 resume tokens Created: 21/Sep/23  Updated: 22/Jan/24  Resolved: 30/Oct/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 6.0.10, 7.0.2, 7.1.0-rc4
Fix Version/s: 7.1.1, 7.2.0-rc0, 6.0.12, 7.0.4

Type: Bug Priority: Major - P3
Reporter: Romans Kasperovics Assignee: Romans Kasperovics
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
Related
related to SERVER-55062 Change stream events can exceed 16MB ... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Backport Requested:
v7.1, v7.0, v6.0
Sprint: QE 2023-10-02, QE 2023-10-16, QE 2023-10-30, QE 2023-11-13
Participants:
Case:

 Description   

With PM-2677 backported to v6.0, change stream pipelines containing the $changeStreamSplitLargeEvent stage generate V2 resume tokens by design.

Customers should be able to add this new stage to their existing change stream pipelines and resume using the existing V1 resume tokens, which is v6.0's default. Currently, there is a bug in compareAgainstClientResumeToken() resulting in ChangeStreamFatalError: cannot resume stream; the resume token was not found.



 Comments   
Comment by Githook User [ 09/Nov/23 ]

Author:

{'name': 'Romans Kasperovics', 'email': 'romans.kasperovics@mongodb.com', 'username': 'romanskas'}

Message: SERVER-81295 Fix v1/v2 change stream resume token transition

Change stream implementation assumes change events are totally ordered by event '_id', which also serves as a resume token. In server versions prior to v7.0 the default resume token version is v1. Starting from v7.0 the default resume token version is v2, but the server still supports clients supplying v1 resume tokens (e.g., after server upgrade).

The token version is a part of a token and all v1 tokens sort before v2 tokens. To ensure the correct event ordering, the server from v7.0 generates v1 tokens to be compared with the client's v1 token until the referred event is either located or surpassed.

In this commit we fix the following issues:

  • When resuming from the event within a transaction we need to consider 'txnOpIndex', because the whole transaction gets the same timestamp.
  • Splitting large events is only supported with v2 tokens. If a resume token is a high-watermark v1 token, the next event sharing the same timestamp will have token version v1. If this event is over 16MB, splitting it will fail because of the token version. To fix this, we convert the client's high-watermark v1 token to v2.
    Branch: v6.0
    https://github.com/mongodb/mongo/commit/4cf365118b715bca6461d741d4c1edecf1341817
Comment by Githook User [ 07/Nov/23 ]

Author:

{'name': 'Romans Kasperovics', 'email': 'romans.kasperovics@mongodb.com', 'username': 'romanskas'}

Message: SERVER-81295 Fix v1/v2 change stream resume token transition

Change stream implementation assumes change events are totally ordered by event '_id', which also serves as a resume token. In server versions prior to v7.0 the default resume token version is v1. Starting from v7.0 the default resume token version is v2, but the server still supports clients supplying v1 resume tokens (e.g., after server upgrade).

The token version is a part of a token and all v1 tokens sort before v2 tokens. To ensure the correct event ordering, the server from v7.0 generates v1 tokens to be compared with the client's v1 token until the referred event is either located or surpassed.

In this commit we fix the following issues:

  • When resuming from the event within a transaction we need to consider 'txnOpIndex', because the whole transaction gets the same timestamp.
  • Splitting large events is only supported with v2 tokens. If a resume token is a high-watermark v1 token, the next event sharing the same timestamp will have token version v1. If this event is over 16MB, splitting it will fail because of the token version. To fix this, we convert the client's high-watermark v1 token to v2.
    Branch: v7.0
    https://github.com/mongodb/mongo/commit/0a9c07cfa5449fa21a84dd5730bff6427b52db0b
Comment by Githook User [ 03/Nov/23 ]

Author:

{'name': 'Romans Kasperovics', 'email': 'romans.kasperovics@mongodb.com', 'username': 'romanskas'}

Message: SERVER-81295 Fix v1/v2 change stream resume token transition

Change stream implementation assumes change events are totally ordered by event '_id', which also serves as a resume token. In server versions prior to v7.0 the default resume token version is v1. Starting from v7.0 the default resume token version is v2, but the server still supports clients supplying v1 resume tokens (e.g., after server upgrade).

The token version is a part of a token and all v1 tokens sort before v2 tokens. To ensure the correct event ordering, the server from v7.0 generates v1 tokens to be compared with the client's v1 token until the referred event is either located or surpassed.

In this commit we fix the following issues:

When resuming from the event within a transaction we need to consider 'txnOpIndex', because the whole transaction gets the same timestamp.
Splitting large events is only supported with v2 tokens. If a resume token is a high-watermark v1 token, the next event sharing the same timestamp will have token version v1. If this event is over 16MB, splitting it will fail because of the token version. To fix this, we convert the client's high-watermark v1 token to v2.
Branch: v7.1
https://github.com/mongodb/mongo/commit/7755281ad25f987d7cbc4e9feb5d09432796fe41

Comment by Githook User [ 29/Oct/23 ]

Author:

{'name': 'Romans Kasperovics', 'email': 'romans.kasperovics@mongodb.com', 'username': 'romanskas'}

Message: SERVER-81295 Fix v1/v2 change stream resume token transition

Change stream implementation assumes change events are totally
ordered by event '_id', which also serves as a resume token.
In server versions prior to v7.0 the default resume token version
is v1. Starting from v7.0 the default resume token version is v2,
but the server still supports clients supplying v1 resume tokens
(e.g., after server upgrade).

The token version is a part of a token and all v1 tokens sort before
v2 tokens. To ensure the correct event ordering, the server from v7.0
generates v1 tokens to be compared with the client's v1 token until
the referred event is either located or surpassed.

In this commit we fix the following issues:

  • When resuming from the event within a transaction we need to
    consider 'txnOpIndex', because the whole transaction gets the same
    timestamp.
  • Splitting large events is only supported with v2 tokens. If a
    resume token is a high-watermark v1 token, the next event sharing
    the same timestamp will have token version v1. If this event is
    over 16MB, splitting it will fail because of the token version. To
    fix this, we convert the client's high-watermark v1 token to v2.
    Branch: master
    https://github.com/mongodb/mongo/commit/24bb8e2f5be1cf103f7e2c5da524186e738cab5d
Generated at Thu Feb 08 06:46:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.