We had originally merged SERVER-93521, which added validation that would reject queries that referenced "searchScore" or "vectorSearchScore" in a context where that metadata wouldn't be available (for example, a query would be rejected for referencing "searchScore" in a query without a $search stage).

The team then decided it would be preferable to first (in 8.2) add a warning log line. The related SERVER ticket implemented the new behavior to print the warning in 8.2. Customers should be notified in the warning is found in their cluster's logs so they can fix their queries in advance of 8.3, where the strict validation will be enabled.

Description of Linked Ticket

We should add a deprecation notice instead of uasserting so that customers have longer to adapt to the change in behavior.

We still intend to have the error appear in 8.3 so this can target 8.2 directly.

Non-assignee request: What is the reason for requesting this backport?

• We knowingly introduced a breaking change in SERVER-93521 which lands in 8.2. This change throws an error for malformed queries that reference "searchScore" or "vectorSearchScore" when unavailable in the pipeline. This should help users identify unintended behavior in their query. However, we decided users should have some more notice in case this may break their queries. This backport will have 8.2 log a warning instead of throwing an error. Then in 8.3, the error will be thrown. In the 8.2 time window, users can fix their queries so they don't fail during the 8.3 upgrade.

Could this introduce any (intentional or unintentional) breaking changes? Please explain.

• No. This removes a breaking change in 8.2.

Could this change unintentionally cause tests to fail or introduce risk to internal tools and test infrastructure?

• We do need to be careful about testing since the error-versus-logging behavior is tricky to test, but I do believe we've been comprehensive enough with the testing.

What is the risk and potential customer impact of backporting this (or not backporting this)?

• If we do not backport this, working queries (that incorrectly reference "searchScore" or "vectorSearchScore" may start breaking during 8.2 upgrade.