[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: |
|
||||||||||||
| 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:
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: |
| 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. |