MeiliSearch/.github/ISSUE_TEMPLATE/sprint_issue.md

name	about	title	labels	assignees
New sprint issue	⚠️ Should only be used by the engine team ⚠️		missing usage in PRD, impacts docs

Related product team resources: PRD (internal only) Related product discussion:

Motivation

Usage

TODO

Are you modifying a database?

• If not, add the no db change label to your PR, and you're good to go.
• If yes, add the db change label to your PR and you're good to go.
  • /!\ Ensure all the read operations still work!
    • If the change happened in milli, you may need to check the version of the database before doing any read operation
    • If the change happened in the index-scheduler, make sure the new code can immediately read the old database
    • If the change happened in the meilisearch-auth database, reach out to the team; we don't know yet how to handle these changes
  • Write the code to go from the old database to the new one
    • If the change happened in milli, the upgrade function should be written and called here
    • If the change happened in the index-scheduler, we've never done it yet, but the right place to do it should be here
  • Write an integration test here ensuring you can read the old database, upgrade to the new database, and read the new database as expected

Reminders when modifying the API

• Update the openAPI file with utoipa:
  • If a new module has been introduced, create a new structure deriving the OpenAPI proc-macro and nest it in the main openAPI structure.
  • If a new route has been introduced, add the path decorator to it and add the route at the top of the file in its openAPI structure.
  • If a structure which is deserialized or serialized in the API has been introduced or modified, it must derive the schema or the IntoParams proc-macro. If it's a new structure you must also add it to the big list of structures in the main OpenApi structure.
  • Once everything is done, start Meilisearch with the swagger flag: cargo run --features swagger, open http://localhost:7700/scalar on your browser, and ensure everything works as expected.
  • For more info, refer to this presentation.

Reminders when modifying the Setting API

• Ensure the new setting route is at least tested by the test_setting_routes macro
• Ensure Analytics are fully implemented
  • /settings/my-new-setting configurated in the make_setting_routes macro
  • global /settings route configurated in the update_all function
• Ensure the dump serializing is consistent with the /settings route serializing, e.g., enums case can be different (camelCase in route and PascalCase in the dump)

Special cases when adding a setting for an experimental feature

• ⚠️ API stability: The setting does not appear on the main settings route when the feature has never been enabled (e.g. mark it Unset when returned from the index in this situation. See an example)
• The setting cannot be set when the feature is disabled, either by the main settings route or the subroute (see validate_settings function)
• If possible, the setting is reset when the feature is disabled (hard if it requires reindexing)

Impacted teams