[SERVER-79508] Investigate removing StubMongoProcessInterface from production use Created: 31/Jul/23  Updated: 25/Jan/24

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

Type: Improvement Priority: Major - P3
Reporter: Alyssa Clark Assignee: Backlog - Query Integration
Resolution: Unresolved Votes: 0
Labels: qi-tech-debt, query-skunkworks
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-85503 Add an open()-like API to DocumentSou... Backlog
Assigned Teams:
Query Integration
Participants:

 Description   

We check if the mongoProcessInterface that we are dealing with is a StubMongoProcessInterface in a couple of spots for $search/$vectorSearch (example: https://github.com/10gen/mongo-enterprise-modules/blob/22813e8d3255d865dafb7b79d75800465da20c1c/src/search/mongot_cursor.h#L80). This may be the case when parsing the pipeline for QE, pipeline-style updates, and views (at a minimum). We should try to detect these cases other ways so we don't have to check the implementation type.

This check didn't end up being feasible to change. We need to investigate how to get rid of StubMongoProcessInterface from being used in production in the first place.



 Comments   
Comment by Gil Alon [ 30/Nov/23 ]

This issue came up again in SERVER-83003 and we currently rely on the stub interface to detect if we are in query analysis. In SERVER-83003 this was important because query analysis doesn't have access to server parameters we require for validating listSearchIndexes. Additionally, there are two ExpressionContext constructors that explicitly make a stub interface (one when we perform pipeline style updates and another for query shape). So we do rely on the stub interface in production.

Comment by Ted Tuckman [ 12/Oct/23 ]

We would like to move toward a world in which we don't use the stub in production – if there's a straightforward way of changing the existing explicit checks great, if not we can postpone this.

Comment by Maddie Zechar [ 12/Oct/23 ]

Ok if this is a step toward removing the stub interface, heard. 

 

I checked in with Jacob who wrote the original code and disagreed that type checking is slow.

 

But I'll move forward in the interest of getting rid of the stub interface eventually? cc ted.tuckman@mongodb.com 

Comment by Alyssa Clark [ 11/Oct/23 ]

Ideally we wouldn't use the stub interface in production at all, so this is a step towards that. I don't remember much context beyond that - ted.tuckman@mongodb.com IIRC you were advocating for this ticket being created, do you remember any other reasoning for it? 

Comment by Maddie Zechar [ 11/Oct/23 ]

Got it - could you please explain why you feel that the code linked is bad?

Comment by Alyssa Clark [ 11/Oct/23 ]

This ticket is just about avoiding the type checking for the stub interface. 

Comment by Maddie Zechar [ 11/Oct/23 ]

alyssa.wagenmaker@mongodb.com – want to confirm before BF days tmrw, is the issue here that we shouldn't have stubs in production at all? Or the issue is with type checking subclasses?

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