Summarize IDL changes re Compatibility Notes API V1 (DOCS-14385)

[DOCS-14129] Investigate changes in SERVER-53739: Temporary code to validate all createIndexes options Created: 14/Jan/21  Updated: 13/Nov/23  Resolved: 27/Apr/21

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: 5.1.0-rc0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Sub-task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Joseph Dougherty
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-53739 Validate all createIndexes options Closed
Participants:
Days since reply: 2 years, 41 weeks, 1 day ago

 Description   

Description

Downstream Change Summary

The createIndexes command had permitted values of the wrong type for at least some of the following options: background, unique, sparse, finestIndexedLevel, coarsestIndexedLevel, dropDups, weights, default_language, language_override, wildcardProjection, 2dsphereIndexVersion, textIndexVersion, bits, min, and max. In SERVER-52545 and SERVER-53739, I have tightened up validation for these createIndexes options. Sara Goleman is further tightening validation in the upcoming SERVER-52539, and her changes will ban unrecognized options.

All valid invocations of createIndexes should work the same as before, but misformatted invocations that had silently misbehaved heretofore will be rejected henceforth.

Description of Linked Ticket

My change to the "listIndexes" IDL (SERVER-52545) has caused an intermittent failure in jstestfuzz_replication_initsync, I think this is the sequence:

  • the fuzzer generates a createIndexes command like {createIndexes: [ {key: "foo", dropDups: "some string"}

    ]}

  • that's wrong because "dropDups" is supposed to be a bool, but createIndexes succeeds anyway (its parameter validation is spotty, awaiting SERVER-52539) and creates a corrupt catalog entry
  • subsequent "listIndexes" commands fail with a uassert, because they now strictly parse the catalog entries. The message is like: "Could not parse catalog entry while replying to listIndexes"
  • initial sync is now impossible because the sync source can't answer "listIndexes". The initial-sync node crashes, logging:

    > "Fatal assertion","attr":{"msgid":40088,"error":"InitialSyncFailure: error cloning databases :: caused by :: Location5254501: Error cloning collection 'qa450.existingname' :: caused by :: listIndexes failed: { ok: 0.0, errmsg: \"Could not parse catalog entry while replying to listIndexes\", code: 5254501, codeName: \"Location5254501\",
    

    This will be fixed by SERVER-52539 "Specify input/output to createIndexes command in IDL", which will make createIndexes as strict as listIndexes. But I want to fix the BF sooner than that, so this ticket is a bandaid.

(In retrospect, we should've converted createIndexes before listIndexes, but I didn't anticipate this issue.)

I made createIndexes validate the "background" option in this commit, now I'll validate the rest of the options.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Joseph Dougherty [ 27/Apr/21 ]

The createIndexes command is documented on the 5.0 Compatibility Changes page:
https://jira.mongodb.org/browse/DOCS-14385

Command behavior re rejecting invalid arguments is documented on the Versioned API page:
https://jira.mongodb.org/browse/DOCSP-15027

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