[SERVER-74581] Ensure AsyncRequestMerger is constructed with valid TaskExecutor Created: 03/Mar/23  Updated: 27/Oct/23  Resolved: 27/Oct/23

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

Type: Improvement Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Tommaso Tocci
Resolution: Won't Do Votes: 0
Labels: car-qw, neweng, sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding EMEA
Sprint: Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03, Sharding EMEA 2023-06-26, Sharding EMEA 2023-07-10, Sharding EMEA 2023-07-24, Sharding EMEA 2023-08-07, Sharding EMEA 2023-08-21, Sharding EMEA 2023-09-04, Sharding EMEA 2023-09-18, Sharding EMEA 2023-10-02, Sharding EMEA 2023-10-16, Sharding EMEA 2023-10-30
Participants:
Story Points: 1

 Description   

When populating DocumentSourceMergeCursors we extract the TaskExecutor from the MongoProcessInterface of the given epression context. This is not always safe because the MongoProcessInterface could be built with a null executor.

In case a null executor is used the underlying BlockingResultsMerger will through a Segfault on first execution of getNext, that is difficult to debug.

In order to ease the debug process and early detect those programming errors I would suggest to use invariants to ensure the TaskExecutor is valid when populating the DocumentSourceMergeCursor stage.

Additionally we should ask similar invariant in the constructor of AsyncResultsMerger.


Generated at Thu Feb 08 06:27:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.