[SERVER-24198] When planning fails because there is no way to answer the query, it should emit ErrorCodes::NoQueryExecutionPlans Created: 18/May/16  Updated: 06/Dec/22  Resolved: 08/Oct/19

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

Type: Improvement Priority: Major - P3
Reporter: Tyler Brock Assignee: Backlog - Query Team (Inactive)
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-43202 Aggregation system can continue tryin... Closed
Assigned Teams:
Query
Participants:
Case:

 Description   

The planner now uses ErrorCodes::BadValue when it fails due to the absence of any available query solutions. This is too generic. Instead we should introduce ErrorCodes::NoQuerySolutions in order to allow clients to check for this particular error case.

Original description

I'm doing some work trying to get MongoDB 3.2 to work with parse-server. parse-server has a feature where if you do a geo query and don't have the appropriate index, it catches the error, creates the index, then retries the query. Previously this worked by catching the error code 17007 but in MongoDB 3.2 it appears that this error code is now 2.

I wanted to check if this was expected behavior before coding around the issue.



 Comments   
Comment by David Storch [ 08/Oct/19 ]

This improvement was completed as part of related ticket SERVER-43202, so I'm closing this ticket as "gone away". The improvement will be available as of version 4.2.1. When a query fails because no plan is available, then the operation should fail with code 291, "NoQueryExecutionPlans". This can happen if --notablescan is enabled, or if a required index (e.g. a geospatial or text index) is missing.

Comment by Matthew Monteleone [ 03/Sep/19 ]

As an additional perspective on this....

 

Since this option is exposed in the Atlas interface, more customers with less experience with MongoDb may be faced with the current error message. The current error message can be a bit cryptic to these users.

The more specific {{NoQuerySolutionMissingRequiredIndex }}could be very useful in reducing customer frustration and reducing support load.

Comment by David Storch [ 18/May/16 ]

Ah, thanks dstorch. Can we add something like ErrorCodes::NoQuerySolutionMissingRequiredIndex to make it more explicit or is that too verbose and specific?

I think NoQuerySolutions is better. The only way this can happen is 1) you issue a geoNear query without the right geo index, 2) you issue a text query without a text index, or 3) the plan would be a collection scan but you have disabled collection scans via --notablescan.

In your mind what would the best way to catch this particular error for a missing 2d index for a geo query on MongoDB spanning multiple versions? Would a regex match for "unable to find index for $geoNear query" on error message do the trick or is there a better way?

Definitely not ErrorCodes::BadValue . You could rely on the text of the error message, though that may not be a great workaround. Otherwise I can't think of a trick besides using listIndexes to ensure that the appropriate indices exist on the collection.

Comment by Tyler Brock [ 18/May/16 ]

Ah, thanks dstorch. Can we add something like ErrorCodes::NoQuerySolutionMissingRequiredIndex to make it more explicit or is that too verbose and specific?

In your mind what would the best way to catch this particular error for a missing 2d index for a geo query on MongoDB spanning multiple versions? Would a regex match for "unable to find index for $geoNear query" on error message do the trick or is there a better way?

Comment by David Storch [ 18/May/16 ]

I would say this is expected behavior. The query planner has always issued ErrorCodes::BadValue when it detects that a $near query cannot be answered in the absence of a matching geospatial index. Previous versions of the server converted this error status into a user assertion exception with code 17007 in order to propagate the error to the client. In 3.2, we made a change that caused us to propagate the original error status rather than changing it to 17007. (By the way, 17007 was never reserved for this particular geo-related error case; I think there are many kinds of query planning or query execution errors that could result in 17007.)

That said, I think we could be using a better / more specific error code here instead of ErrorCodes::BadValue. I'm going to repurpose this ticket as a request to add ErrorCodes::NoQuerySolution.

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