[SERVER-29140] Return 'invalidate' entries and close the cursor on relevant drop, dropDatabase, and renameCollection oplog entries Created: 11/May/17  Updated: 30/Oct/23  Resolved: 09/Aug/17

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

Type: Task Priority: Major - P3
Reporter: Crystal Horn Assignee: Siyuan Zhou
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-10668 Docs for SERVER-29140: Return 'invali... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2017-07-31, Repl 2017-08-21
Participants:

 Description   

If someone was trying to use changeNotifications to keep a cache in sync with changes to a mongodb collection or database, certain operations would cause that cache to need to be invalidated, namely drop, dropDatabase, and renameCollection operations that affect the collection or database that notifications are being received on. When a change notification feed encounters one of those operations it should return an 'invalidate' entry and close the change notification cursor



 Comments   
Comment by Githook User [ 10/Aug/17 ]

Author:

{'name': 'Siyuan Zhou', 'email': 'siyuan.zhou@mongodb.com'}

Message: SERVER-29140 Close cursor for invalidate change notification entries.
Branch: master
https://github.com/mongodb/mongo/commit/a73070d49470cd0ff1f7d2f5189b59d231e5c9ff

Comment by Githook User [ 10/Aug/17 ]

Author:

{'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com'}

Message: Revert "SERVER-29140 Close cursor for invalidate change notification entries."

This reverts commit a73070d49470cd0ff1f7d2f5189b59d231e5c9ff.
Branch: master
https://github.com/mongodb/mongo/commit/ddcc982e9b1ecca89fc315d698990176ba73df25

Comment by Githook User [ 09/Aug/17 ]

Author:

{'username': 'visualzhou', 'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou'}

Message: SERVER-29140 Close cursor for invalidate change notification entries.

This reverts commit ddcc982e9b1ecca89fc315d698990176ba73df25.
Branch: master
https://github.com/mongodb/mongo/commit/c1aee1915536be2d1928d1098e133acbfdc3a575

Comment by Siyuan Zhou [ 07/Aug/17 ]

The comparison behavior is surprising to me.

$ mongo-3.4 --nodb
MongoDB shell version v3.4.3
> a = NumberLong(0)
NumberLong(0)
> assert.eq(a, 0)
> assert.neq(a, 1)
> assert.neq(a, 0)
assert: [0] != [0] are equal : undefined
doassert@src/mongo/shell/assert.js:18:14
assert.neq@src/mongo/shell/assert.js:131:5
@(shell):1:1
 
2017-08-07T18:20:05.377-0400 E QUERY    [thread1] Error: [0] != [0] are equal : undefined :
doassert@src/mongo/shell/assert.js:18:14
assert.neq@src/mongo/shell/assert.js:131:5
@(shell):1:1
> assert.neq(a, NumberLong(0))       // This is surprising.
> assert.eq(a, NumberLong(0))
> a
NumberLong(0)
> exit
bye

Comment by Siyuan Zhou [ 07/Aug/17 ]

max.hirschhorn, thanks for the debugging! I'm investigating the failure. For the issue of comparison, maybe we should fix assert.neq() as the same as assert.eq() using friendlyEqual()?

Comment by Max Hirschhorn [ 04/Aug/17 ]

I reverted the changes from a73070d under ddcc982 due to the jstests/aggregation/sources/changeNotification/change_notification_invalidation.js test consistently failing. See this aggregation task as an example of a failure.

On a separate note, siyuan.zhou, I'd be careful about using assert.neq() when comparing a cursor id returned by the server. It'll get deserialized by the mongo shell as a NumberLong instance, so the != in assert.neq() will compare the by-object references (rather than by-value) and always return false. I'd suggest asserting on the return value of bsonWoCompare() or bsonBinaryEqual() to be explicit and work around JavaScript's comparison semantics.

Comment by Siyuan Zhou [ 14/Jul/17 ]

We should include a test case where the client is able to resume from an "invalidate" entry.

Generated at Thu Feb 08 04:20:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.