[SERVER-47168] ensure replication of the system.js collection in system_js_access test Created: 27/Mar/20  Updated: 08/Jan/24  Resolved: 20/Apr/20

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

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: David Percy
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-47445 Scope can forget to load system.js pr... Closed
Related
Operating System: ALL
Sprint: Query 2020-05-04
Participants:
Linked BF Score: 32

 Description   

The error occurs in a hedge read that goes to secondary before the collection that contains js function definition is replicated:

assert: command did not fail with any of the following codes [ 4649200 ] {
"ok" : 0,
"errmsg" : "Encountered non-retryable error during query :: caused by :: ReferenceError: isAdult is not defined :\n@:1:15\n",
"code" : 139,
"codeName" : "JSInterpreterFailure",
"operationTime" : Timestamp(1585298452, 13),
"$clusterTime" : {
"clusterTime" : Timestamp(1585298452, 13),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}

A possible quick fix is to ensure the insert of js function is replicated.



 Comments   
Comment by David Percy [ 20/Apr/20 ]

This test failure turned out to be a bug in the JS Scope class (not replication) which is now fixed: SERVER-47445

Comment by Misha Tyulenev [ 30/Mar/20 ]

Thank you max.hirschhorn for bringing this up, agreed that while it may be an indication of causal consistency anomaly from the outside - i.e. the writes to system.js apparently not reflected in the secondary reads - the failure on the standalone indicates different root cause. will look more into that.

Comment by Max Hirschhorn [ 30/Mar/20 ]

Given my comment on BF-16735 how this error also happens on a stand-alone mongod, I'm not sure there is a "failing to wait for replication" kind of issue going on here. Furthermore, I'd fully expect the find command with a $where would have an afterClusterTime of the operation time from the insert into the system.js collection. A secondary being targeted by such a find command would wait for the read concern prior to constructing a Scope instance.

For the case that mira.carey@mongodb.com brought up about the Scope instances being pooled, there is an OpObserver registered for inserts, updates, and deletes on the system.js collection. It bumps a global generation counter which will cause the PooledScope to load the contents of the system.js collection when it is take out of the pool again.

Generated at Thu Feb 08 05:13:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.