docs: restore details lost during OpenAPI migration#3558
Open
docs: restore details lost during OpenAPI migration#3558
Conversation
Restores 87 granular documentation details (warnings, defaults, semantics, gotchas, incompatibilities) across 17 areas that were dropped when per-endpoint reference docs were replaced by OpenAPI-rendered pages. Adds three new how-to pages (facet_search, configure_dictionary, tune_distribution) and integrates the remaining prose into existing capability pages as callouts, notes, and reference tables.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
📝 WalkthroughWalkthroughWidespread documentation updates: added new how-to pages (dictionary, facet search, distribution tuning), expanded conversational-search and hybrid-search docs, clarified index/task/embedding behaviors, added code samples/snippets, and updated navigation entries. All changes are documentation-only. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
capabilities/conversational_search/how_to/configure_chat_workspace.mdx (1)
66-80:⚠️ Potential issue | 🟠 MajorAzure OpenAI example is missing required fields.
The table and prose (lines 46 and 52) declare
orgIdandprojectIdas required for Azure OpenAI, but the example payload (lines 71-77) omits both fields. Update the example to include them:Suggested fix
--data-binary '{ "source": "azureOpenAi", "apiKey": "YOUR_AZURE_API_KEY", "baseUrl": "https://your-resource.openai.azure.com", + "orgId": "YOUR_AZURE_ORG_ID", + "projectId": "YOUR_AZURE_PROJECT_ID", "deploymentId": "your-deployment-id", "apiVersion": "2024-02-01" }'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/conversational_search/how_to/configure_chat_workspace.mdx` around lines 66 - 80, The Azure OpenAI cURL example payload in the code block for configuring chat workspace is missing the required "orgId" and "projectId" fields; update the JSON body in the PATCH example (the cURL block that patches '.../chats/my-support-bot/settings') to include "orgId": "YOUR_ORG_ID" and "projectId": "YOUR_PROJECT_ID" as placeholders alongside "source", "apiKey", "baseUrl", "deploymentId", and "apiVersion" so the example matches the documented required fields.
🧹 Nitpick comments (11)
capabilities/indexing/how_to/handle_multilingual_data.mdx (1)
122-122: Split the long explanatory sentence for readability.Line 122 is doing too much in one sentence. Consider splitting it into two short sentences to keep the guidance easier to scan.
Suggested edit
-If the `locales` search parameter and the `localizedAttributes` index setting disagree, `locales` wins. The value passed on the query takes precedence over the index-level configuration for that request. This is useful when a user explicitly picks a language in your UI (for example, a locale switcher), but it also means a mis-specified `locales` value can override your carefully tuned index settings for that one search. +If the `locales` search parameter and the `localizedAttributes` index setting disagree, `locales` wins. The query value takes precedence over the index-level configuration for that request. +This is useful when a user explicitly picks a language in your UI (for example, a locale switcher). However, a mis-specified `locales` value can override your index settings for that one search.As per coding guidelines, “Prefer shorter sentences; if a sentence runs over approximately 40 words, consider splitting or simplifying”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/indexing/how_to/handle_multilingual_data.mdx` at line 122, The sentence explaining precedence between the locales search parameter and the localizedAttributes index setting is too long; split it into two shorter sentences to improve readability and scanning. Specifically, edit the paragraph that mentions locales and localizedAttributes so the first sentence states that locales wins (the query value takes precedence) and the second sentence briefly explains when this is useful (e.g., user picks a language via UI) and warns about mis-specified locales overriding index-level configuration for that request.capabilities/full_text_search/how_to/highlight_search_results.mdx (2)
139-139: Use one ellipsis style in examples for consistency.This example uses
…while other snippets/defaults show"...". Using one style across the page avoids ambiguity when readers copy examples.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/full_text_search/how_to/highlight_search_results.mdx` at line 139, Pick a single ellipsis style (either the single-character Unicode ellipsis "…" or three ASCII dots "...") and make all examples and defaults consistent across the document: update the example sentence that describes cropLength (the snippet containing "…Shifu informs…") and any other occurrences so they use the chosen style uniformly, including inline code examples, code blocks, and surrounding quotes; verify search examples and the `cropLength` explanation reflect the same ellipsis character.
46-46: Split this note into shorter sentences for readability.Great detail, but Line 46 is doing too much in one sentence. Splitting it into 2–3 short sentences will make the behavior easier to scan.
As per coding guidelines "Prefer shorter sentences; if a sentence runs over approximately 40 words, consider splitting or simplifying."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/full_text_search/how_to/highlight_search_results.mdx` at line 46, Split the long explanatory sentence into 2–3 shorter sentences for readability: mention that attributesToHighlight will wrap matches in any listed attribute; clarify that this applies even if those attributes are not in searchableAttributes; and state that Meilisearch won’t generate matches from non-searchable fields but will still highlight verbatim occurrences. Keep references to attributesToHighlight, searchableAttributes, and Meilisearch as shown so the meaning stays exact.resources/self_hosting/sharding/manage_network.mdx (1)
138-142: Add links to related settings guides for faster remediation.This warning is important, but it would be more actionable with direct links to
displayedAttributesandsortableAttributesdocs in the same paragraph.As per coding guidelines, "When adding or moving content, update or add links from related pages so users can find it."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@resources/self_hosting/sharding/manage_network.mdx` around lines 138 - 142, Update the warning paragraph in manage_network.mdx to include inline links to the documented settings for displayedAttributes and sortableAttributes so users can remediate quickly: modify the paragraph that mentions `displayedAttributes`, `sortableAttributes`, and the `/network` endpoint to insert anchor links to the respective docs/guides for displayedAttributes and sortableAttributes (ensure the link text matches the symbol names `displayedAttributes` and `sortableAttributes`), keeping the warning content intact and placing both links in the same sentence for immediate access.capabilities/full_text_search/how_to/configure_searchable_attributes.mdx (1)
77-79: Consider splitting this warning into shorter sentences.The behavior is correct, but the paragraph is dense. Breaking it into two short statements plus the example would improve scanability.
As per coding guidelines, "Prefer shorter sentences; if a sentence runs over approximately 40 words, consider splitting or simplifying."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/full_text_search/how_to/configure_searchable_attributes.mdx` around lines 77 - 79, Split the dense warning into two shorter sentences to improve readability: first state that attributesToSearchOn restricts searches to only the listed fields, and then state that documents matching only other searchable fields will be excluded (no error raised); keep the concrete example showing searchableAttributes vs attributesToSearchOn (e.g., searchableAttributes: ["title","overview","genre"] with attributesToSearchOn: ["overview"]) immediately after to illustrate the behavior. Mention the absence of an error briefly in the second short sentence.capabilities/filtering_sorting_faceting/how_to/facet_search.mdx (1)
15-16: Split this semicolon sentence into two sentences.This reads cleaner and aligns better with the docs style guidance.
Proposed edit
-Before you can search a facet's values, the attribute must be declared in [`filterableAttributes`](/capabilities/filtering_sorting_faceting/getting_started). Facet search is enabled by default on every index; you can disable it per index with the `facetSearch` setting if you do not need it and want to speed up indexing. +Before you can search a facet's values, the attribute must be declared in [`filterableAttributes`](/capabilities/filtering_sorting_faceting/getting_started). Facet search is enabled by default on every index. You can disable it per index with the `facetSearch` setting if you do not need it and want to speed up indexing.As per coding guidelines, "Use semicolons sparingly; prefer splitting into two sentences or rewording for clarity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/filtering_sorting_faceting/how_to/facet_search.mdx` around lines 15 - 16, Split the semicolon-joined sentence into two separate sentences in the paragraph that begins "Before you can search a facet's values, the attribute must be declared..." — make the first sentence end after "getting_started)." and start a new sentence with "Facet search is enabled by default on every index." Also keep the note about disabling per index with the `facetSearch` setting in that second sentence (e.g., "You can disable it per index with the `facetSearch` setting if you do not need it and want to speed up indexing.") so the content remains identical but uses two sentences instead of a semicolon.capabilities/full_text_search/how_to/configure_dictionary.mdx (1)
11-11: Consider splitting this definition sentence for readability.The sentence is dense and can be easier to scan if split into two shorter sentences.
Proposed edit
-The `dictionary` setting allows you to instruct Meilisearch to consider groups of strings as a single term by adding a supplementary dictionary of user-defined terms. Entries in the dictionary override the default tokenizer, so Meilisearch will recognize them as indivisible tokens during both indexing and search. +The `dictionary` setting lets you treat groups of strings as a single term by adding a supplementary dictionary of user-defined terms. Dictionary entries override the default tokenizer, so Meilisearch recognizes them as indivisible tokens during indexing and search.As per coding guidelines, "Prefer shorter sentences; if a sentence runs over approximately 40 words, consider splitting or simplifying."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/full_text_search/how_to/configure_dictionary.mdx` at line 11, Split the long definition sentence about the `dictionary` setting into two clearer sentences: first state that the `dictionary` setting lets you add a supplementary dictionary of user-defined terms that instructs Meilisearch to treat groups of strings as single terms; then follow with a second sentence noting that dictionary entries override the default tokenizer so Meilisearch recognizes those entries as indivisible tokens during both indexing and search. Update the sentence containing "`dictionary` setting allows you to instruct Meilisearch..." accordingly to improve readability.capabilities/indexing/tasks_and_batches/manage_task_database.mdx (1)
84-84: Nit: align phrasing withasync_operations.mdxfor consistency.This file uses
1 million/100,000, whilecapabilities/indexing/tasks_and_batches/async_operations.mdx(line 211) uses1M/100Kfor the same limits. Consider harmonizing so readers encounter the same wording across pages.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/indexing/tasks_and_batches/manage_task_database.mdx` at line 84, Update the phrasing in the sentence that currently reads "Meilisearch stores up to **1 million tasks** ... delete the oldest **100,000 finished tasks**" to match the style used in async_operations.mdx (use "1M" and "100K"); locate that sentence in manage_task_database.mdx and replace "1 million" with "1M" and "100,000" with "100K" so the two pages use consistent numeric shorthand.capabilities/indexing/tasks_and_batches/filter_tasks.mdx (1)
31-69: Clarify scope of the "comma-separated values" statement.Line 33 says "All parameters below accept comma-separated values", but this only applies to the first table. Pagination parameters (
limit,from,reverse) on lines 65-69 are scalars and do not accept comma-separated values. Recommend rewording to scope the claim to the immediately following table, and while you are editing this section:
- Line 41 (
indexUids): the "Case-sensitive" note is useful but the row omits the "Separate multiple values with a comma" hint present on sibling rows; worth aligning for consistency.- Line 69 (
reverse): "returns results in reverse order, from oldest to most recent" is slightly confusing; consider "returns results from oldest to most recent (reverse of the default)".✍️ Suggested rewording
-All parameters below accept comma-separated values. Filters of different types are combined with a logical `AND`. +The parameters in the following table accept comma-separated values. Filters of different types are combined with a logical `AND`. @@ -| `indexUids` | Filter tasks by their `indexUid`. Case-sensitive. | +| `indexUids` | Filter tasks by their `indexUid`. Separate multiple `indexUids` with a comma (`,`). Case-sensitive. | @@ -| `reverse` | If `true`, returns results in reverse order, from oldest to most recent. Defaults to `false`. | +| `reverse` | If `true`, returns results from oldest to most recent (reverse of the default order). Defaults to `false`. |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/indexing/tasks_and_batches/filter_tasks.mdx` around lines 31 - 69, The opening sentence "All parameters below accept comma-separated values" incorrectly scopes to the entire section; change it to apply only to the first table (the filter parameters) by rewording to something like "The filter parameters in the table below accept comma-separated values." In the first table align the indexUids row with other multi-value rows by adding "Separate multiple indexUids with a comma (`,`)" and keep the "Case-sensitive" note. In the Pagination parameters table, ensure it's clear these are scalar values and do not accept comma-separated lists (explicitly remove them from scope) and rephrase the reverse description to "returns results from oldest to most recent (reverse of the default)" for clarity; update the rows for limit, from, and reverse accordingly.resources/self_hosting/webhooks.mdx (2)
36-48: Scope alignment: consider reader context.This page focuses on configuring webhooks via instance options (line 10: "configure a single webhook via instance options"). However, the new "Limits and constraints" section primarily discusses the
/webhooksAPI route:
- The first note describes the 20-webhook limit for the API route
- The third note about Cloud internal webhooks applies only to the API route
While the authorization redaction warning applies to both methods, readers following this guide might find the API-centric constraints less relevant. Consider whether a brief introductory sentence could clarify which constraints apply to instance options versus the API route, or whether some items belong on the
/webhooksAPI reference page instead.That said, per the PR objectives this restores prose lost during migration, so the placement may be intentional for discoverability.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@resources/self_hosting/webhooks.mdx` around lines 36 - 48, Update the "Limits and constraints" block to clarify scope: add a brief sentence after the existing "configure a single webhook via instance options" text stating which notes apply to instance options versus the /webhooks API route (e.g., "The following limits apply to the /webhooks API route; instance options configure a single webhook and are not subject to the 20-webhook limit"). Move or mark the two API-specific notes (the 20-webhook limit and Cloud internal webhooks) as API-route-specific, and keep the Authorization header redaction warning generalized since it applies to both instance options and the API; reference the headings/phrases "configure a single webhook via instance options", "Limits and constraints", and the Authorization redaction Warning when making these edits.
38-40: Consider more direct phrasing.The phrase "Having many webhooks active at the same time" can be shortened for clarity and directness.
✨ Suggested refinement
<Note> -You can create up to 20 webhooks per instance via the [`/webhooks` API route](/reference/api/webhooks). Having many webhooks active at the same time may negatively impact performance, so only register the webhooks you actively need. +You can create up to 20 webhooks per instance via the [`/webhooks` API route](/reference/api/webhooks). Many active webhooks may negatively impact performance, so only register the webhooks you actively need. </Note>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@resources/self_hosting/webhooks.mdx` around lines 38 - 40, Rewrite the Note sentence to be more direct and concise: replace "Having many webhooks active at the same time may negatively impact performance, so only register the webhooks you actively need." (the Note block in resources/self_hosting/webhooks.mdx) with a shorter phrasing such as "Many active webhooks can hurt performance; register only the ones you need." Ensure the change preserves the warning and guidance but uses the more direct language.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@capabilities/conversational_search/getting_started/setup.mdx`:
- Line 32: Replace British English spelling "authorises" with American English
"authorizes" in the sentence that explains the Default Chat API Key and in the
clause describing the two required actions for conversational search; update
both occurrences near the phrase "Default Chat API Key" and the reference to the
"/chats" routes so the text reads "chatCompletions authorizes the LLM call, and
search authorizes the retrieval step".
- Around line 22-27: The PATCH example that enables chat completions is missing
the Authorization header; update the curl example that targets
'experimental-features' (the PATCH block setting "{ \"chatCompletions\": true
}") to include the same authentication header used elsewhere (e.g., -H
'Authorization: Bearer MEILISEARCH_KEY') so the request succeeds against a
master-key protected self-hosted instance and matches other examples on the
page.
In `@capabilities/conversational_search/overview.mdx`:
- Line 8: Update the American English spelling in the sentence that currently
reads "...and configure
[guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to
minimise this risk." Replace "minimise" with "minimize" in the content of
capabilities/conversational_search/overview.mdx so the line reads "...and
configure
[guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to
minimize this risk."
In `@capabilities/full_text_search/how_to/configure_search_cutoff.mdx`:
- Line 18: The doc contradicts itself about searchCutoffMs: make the behavior
consistent by stating that the configuration default is null (searchCutoffMs =
null) but when no explicit value is provided Meilisearch applies its internal
cutoff of 1500 ms; update the explanatory sentence that currently says "no time
limit" (the reset section) to instead say "resets to the internal Meilisearch
default cutoff of 1500 ms" and ensure both places referencing searchCutoffMs use
the same wording so readers know null != unlimited and that the internal 1500 ms
cutoff applies when unset.
In `@capabilities/hybrid_search/how_to/configure_huggingface_embedder.mdx`:
- Around line 74-77: Update the spelling of "behaviour" to American English
"behavior" in the text that describes HuggingFace model pooling; specifically
change occurrences around the `pooling` field label and the table
header/description where "Behaviour" appears so they read "Behavior".
In `@capabilities/indexing/tasks_and_batches/async_operations.mdx`:
- Around line 186-205: Replace the prose instances of the British spelling
"cancellation" with the single-l American form "cancelation" while leaving the
API identifier taskCancelation unchanged; specifically update the sentence
containing "Because cancellation is an **atomic transaction**" and the sentence
"Like cancellation, task deletion..." to use "cancelation" so narrative text
matches the project style guide.
In `@resources/self_hosting/webhooks.mdx`:
- Around line 42-44: Update the endpoint parameter in the Warning text from GET
/webhooks/{uid} to GET /webhooks/{uuid} so it matches the OpenAPI spec and
navigation config; locate the Warning block that currently contains "GET
/webhooks/{uid}" and replace that segment with "GET /webhooks/{uuid}" and verify
the surrounding sentence remains grammatically correct.
---
Outside diff comments:
In `@capabilities/conversational_search/how_to/configure_chat_workspace.mdx`:
- Around line 66-80: The Azure OpenAI cURL example payload in the code block for
configuring chat workspace is missing the required "orgId" and "projectId"
fields; update the JSON body in the PATCH example (the cURL block that patches
'.../chats/my-support-bot/settings') to include "orgId": "YOUR_ORG_ID" and
"projectId": "YOUR_PROJECT_ID" as placeholders alongside "source", "apiKey",
"baseUrl", "deploymentId", and "apiVersion" so the example matches the
documented required fields.
---
Nitpick comments:
In `@capabilities/filtering_sorting_faceting/how_to/facet_search.mdx`:
- Around line 15-16: Split the semicolon-joined sentence into two separate
sentences in the paragraph that begins "Before you can search a facet's values,
the attribute must be declared..." — make the first sentence end after
"getting_started)." and start a new sentence with "Facet search is enabled by
default on every index." Also keep the note about disabling per index with the
`facetSearch` setting in that second sentence (e.g., "You can disable it per
index with the `facetSearch` setting if you do not need it and want to speed up
indexing.") so the content remains identical but uses two sentences instead of a
semicolon.
In `@capabilities/full_text_search/how_to/configure_dictionary.mdx`:
- Line 11: Split the long definition sentence about the `dictionary` setting
into two clearer sentences: first state that the `dictionary` setting lets you
add a supplementary dictionary of user-defined terms that instructs Meilisearch
to treat groups of strings as single terms; then follow with a second sentence
noting that dictionary entries override the default tokenizer so Meilisearch
recognizes those entries as indivisible tokens during both indexing and search.
Update the sentence containing "`dictionary` setting allows you to instruct
Meilisearch..." accordingly to improve readability.
In `@capabilities/full_text_search/how_to/configure_searchable_attributes.mdx`:
- Around line 77-79: Split the dense warning into two shorter sentences to
improve readability: first state that attributesToSearchOn restricts searches to
only the listed fields, and then state that documents matching only other
searchable fields will be excluded (no error raised); keep the concrete example
showing searchableAttributes vs attributesToSearchOn (e.g.,
searchableAttributes: ["title","overview","genre"] with attributesToSearchOn:
["overview"]) immediately after to illustrate the behavior. Mention the absence
of an error briefly in the second short sentence.
In `@capabilities/full_text_search/how_to/highlight_search_results.mdx`:
- Line 139: Pick a single ellipsis style (either the single-character Unicode
ellipsis "…" or three ASCII dots "...") and make all examples and defaults
consistent across the document: update the example sentence that describes
cropLength (the snippet containing "…Shifu informs…") and any other occurrences
so they use the chosen style uniformly, including inline code examples, code
blocks, and surrounding quotes; verify search examples and the `cropLength`
explanation reflect the same ellipsis character.
- Line 46: Split the long explanatory sentence into 2–3 shorter sentences for
readability: mention that attributesToHighlight will wrap matches in any listed
attribute; clarify that this applies even if those attributes are not in
searchableAttributes; and state that Meilisearch won’t generate matches from
non-searchable fields but will still highlight verbatim occurrences. Keep
references to attributesToHighlight, searchableAttributes, and Meilisearch as
shown so the meaning stays exact.
In `@capabilities/indexing/how_to/handle_multilingual_data.mdx`:
- Line 122: The sentence explaining precedence between the locales search
parameter and the localizedAttributes index setting is too long; split it into
two shorter sentences to improve readability and scanning. Specifically, edit
the paragraph that mentions locales and localizedAttributes so the first
sentence states that locales wins (the query value takes precedence) and the
second sentence briefly explains when this is useful (e.g., user picks a
language via UI) and warns about mis-specified locales overriding index-level
configuration for that request.
In `@capabilities/indexing/tasks_and_batches/filter_tasks.mdx`:
- Around line 31-69: The opening sentence "All parameters below accept
comma-separated values" incorrectly scopes to the entire section; change it to
apply only to the first table (the filter parameters) by rewording to something
like "The filter parameters in the table below accept comma-separated values."
In the first table align the indexUids row with other multi-value rows by adding
"Separate multiple indexUids with a comma (`,`)" and keep the "Case-sensitive"
note. In the Pagination parameters table, ensure it's clear these are scalar
values and do not accept comma-separated lists (explicitly remove them from
scope) and rephrase the reverse description to "returns results from oldest to
most recent (reverse of the default)" for clarity; update the rows for limit,
from, and reverse accordingly.
In `@capabilities/indexing/tasks_and_batches/manage_task_database.mdx`:
- Line 84: Update the phrasing in the sentence that currently reads "Meilisearch
stores up to **1 million tasks** ... delete the oldest **100,000 finished
tasks**" to match the style used in async_operations.mdx (use "1M" and "100K");
locate that sentence in manage_task_database.mdx and replace "1 million" with
"1M" and "100,000" with "100K" so the two pages use consistent numeric
shorthand.
In `@resources/self_hosting/sharding/manage_network.mdx`:
- Around line 138-142: Update the warning paragraph in manage_network.mdx to
include inline links to the documented settings for displayedAttributes and
sortableAttributes so users can remediate quickly: modify the paragraph that
mentions `displayedAttributes`, `sortableAttributes`, and the `/network`
endpoint to insert anchor links to the respective docs/guides for
displayedAttributes and sortableAttributes (ensure the link text matches the
symbol names `displayedAttributes` and `sortableAttributes`), keeping the
warning content intact and placing both links in the same sentence for immediate
access.
In `@resources/self_hosting/webhooks.mdx`:
- Around line 36-48: Update the "Limits and constraints" block to clarify scope:
add a brief sentence after the existing "configure a single webhook via instance
options" text stating which notes apply to instance options versus the /webhooks
API route (e.g., "The following limits apply to the /webhooks API route;
instance options configure a single webhook and are not subject to the
20-webhook limit"). Move or mark the two API-specific notes (the 20-webhook
limit and Cloud internal webhooks) as API-route-specific, and keep the
Authorization header redaction warning generalized since it applies to both
instance options and the API; reference the headings/phrases "configure a single
webhook via instance options", "Limits and constraints", and the Authorization
redaction Warning when making these edits.
- Around line 38-40: Rewrite the Note sentence to be more direct and concise:
replace "Having many webhooks active at the same time may negatively impact
performance, so only register the webhooks you actively need." (the Note block
in resources/self_hosting/webhooks.mdx) with a shorter phrasing such as "Many
active webhooks can hurt performance; register only the ones you need." Ensure
the change preserves the warning and guidance but uses the more direct language.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ea47430e-17b6-468e-b053-1a3aa9f565f1
📒 Files selected for processing (43)
capabilities/conversational_search/getting_started/chat.mdxcapabilities/conversational_search/getting_started/setup.mdxcapabilities/conversational_search/how_to/configure_chat_workspace.mdxcapabilities/conversational_search/how_to/configure_index_chat_settings.mdxcapabilities/conversational_search/how_to/optimize_chat_prompts.mdxcapabilities/conversational_search/how_to/stream_chat_responses.mdxcapabilities/conversational_search/overview.mdxcapabilities/filtering_sorting_faceting/getting_started.mdxcapabilities/filtering_sorting_faceting/how_to/build_faceted_navigation.mdxcapabilities/filtering_sorting_faceting/how_to/facet_search.mdxcapabilities/filtering_sorting_faceting/how_to/sort_results.mdxcapabilities/full_text_search/advanced/performance_tuning.mdxcapabilities/full_text_search/how_to/configure_dictionary.mdxcapabilities/full_text_search/how_to/configure_distinct_attribute.mdxcapabilities/full_text_search/how_to/configure_search_cutoff.mdxcapabilities/full_text_search/how_to/configure_searchable_attributes.mdxcapabilities/full_text_search/how_to/highlight_search_results.mdxcapabilities/full_text_search/how_to/paginate_search_results.mdxcapabilities/full_text_search/overview.mdxcapabilities/full_text_search/relevancy/custom_ranking_rules.mdxcapabilities/full_text_search/relevancy/ranking_score.mdxcapabilities/hybrid_search/advanced/composite_embedders.mdxcapabilities/hybrid_search/advanced/document_template_best_practices.mdxcapabilities/hybrid_search/advanced/tune_distribution.mdxcapabilities/hybrid_search/how_to/configure_huggingface_embedder.mdxcapabilities/hybrid_search/how_to/image_search_with_multimodal.mdxcapabilities/hybrid_search/how_to/search_with_user_provided_embeddings.mdxcapabilities/hybrid_search/overview.mdxcapabilities/indexing/how_to/add_and_update_documents.mdxcapabilities/indexing/how_to/compact_an_index.mdxcapabilities/indexing/how_to/handle_multilingual_data.mdxcapabilities/indexing/overview.mdxcapabilities/indexing/tasks_and_batches/async_operations.mdxcapabilities/indexing/tasks_and_batches/filter_tasks.mdxcapabilities/indexing/tasks_and_batches/manage_task_database.mdxcapabilities/indexing/tasks_and_batches/monitor_tasks.mdxcapabilities/multi_search/overview.mdxcapabilities/security/how_to/manage_api_keys.mdxconfig/navigation.jsonresources/help/experimental_features_overview.mdxresources/internals/documents.mdxresources/self_hosting/sharding/manage_network.mdxresources/self_hosting/webhooks.mdx
| --- | ||
|
|
||
| <Warning> | ||
| **Conversational search is still in early development and conversational agents can hallucinate.** LLMs may occasionally produce inaccurate or misleading answers even when the retrieved source documents are correct. Monitor responses closely in production, follow the [hallucination reduction guide](/capabilities/conversational_search/advanced/reduce_hallucination), and configure [guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to minimise this risk. |
There was a problem hiding this comment.
Use American English spelling: "minimize".
Suggested fix
-**Conversational search is still in early development and conversational agents can hallucinate.** LLMs may occasionally produce inaccurate or misleading answers even when the retrieved source documents are correct. Monitor responses closely in production, follow the [hallucination reduction guide](/capabilities/conversational_search/advanced/reduce_hallucination), and configure [guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to minimise this risk.
+**Conversational search is still in early development and conversational agents can hallucinate.** LLMs may occasionally produce inaccurate or misleading answers even when the retrieved source documents are correct. Monitor responses closely in production, follow the [hallucination reduction guide](/capabilities/conversational_search/advanced/reduce_hallucination), and configure [guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to minimize this risk.As per coding guidelines: "Use American English spelling (e.g., analyze, behavior, color, center, license, canceled, cancelation, program, labeling, initialed, favorite, dependent)".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| **Conversational search is still in early development and conversational agents can hallucinate.** LLMs may occasionally produce inaccurate or misleading answers even when the retrieved source documents are correct. Monitor responses closely in production, follow the [hallucination reduction guide](/capabilities/conversational_search/advanced/reduce_hallucination), and configure [guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to minimise this risk. | |
| **Conversational search is still in early development and conversational agents can hallucinate.** LLMs may occasionally produce inaccurate or misleading answers even when the retrieved source documents are correct. Monitor responses closely in production, follow the [hallucination reduction guide](/capabilities/conversational_search/advanced/reduce_hallucination), and configure [guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to minimize this risk. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@capabilities/conversational_search/overview.mdx` at line 8, Update the
American English spelling in the sentence that currently reads "...and configure
[guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to
minimise this risk." Replace "minimise" with "minimize" in the content of
capabilities/conversational_search/overview.mdx so the line reads "...and
configure
[guardrails](/capabilities/conversational_search/how_to/configure_guardrails) to
minimize this risk."
| The search cutoff sets an upper bound on this processing time. If Meilisearch reaches the cutoff before finishing, it returns the results collected up to that point. These results are still ranked correctly according to the ranking rules, but the result set may not include every possible match. | ||
|
|
||
| By default, the search cutoff is `null`, meaning there is no time limit. | ||
| By default, `searchCutoffMs` is `null`. When no explicit value is configured, Meilisearch interrupts searches after **1500 milliseconds**. Setting `searchCutoffMs` to an integer overrides this internal default with your chosen limit. |
There was a problem hiding this comment.
Resolve internal contradiction about default cutoff behavior.
Line 18 says omitted searchCutoffMs still uses a 1500 ms internal cutoff, but the reset section later says default is “no time limit.” These two statements conflict and can mislead users configuring production limits.
Suggested doc fix
-Remove the search cutoff and return to the default behavior (no time limit):
+Remove the explicit search cutoff and return to the default behavior (`searchCutoffMs: null`, with Meilisearch's internal 1500 ms interruption threshold):🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@capabilities/full_text_search/how_to/configure_search_cutoff.mdx` at line 18,
The doc contradicts itself about searchCutoffMs: make the behavior consistent by
stating that the configuration default is null (searchCutoffMs = null) but when
no explicit value is provided Meilisearch applies its internal cutoff of 1500
ms; update the explanatory sentence that currently says "no time limit" (the
reset section) to instead say "resets to the internal Meilisearch default cutoff
of 1500 ms" and ensure both places referencing searchCutoffMs use the same
wording so readers know null != unlimited and that the internal 1500 ms cutoff
applies when unset.
Comment on lines
+74
to
+77
| HuggingFace models combine per-token output vectors into a single document vector using a pooling strategy. The `pooling` field controls this behaviour: | ||
|
|
||
| | Value | Behaviour | | ||
| |---|---| |
There was a problem hiding this comment.
Use American English spelling: "behavior".
Lines 74 and 77 use "behaviour"; the style guide requires American English.
Proposed fix
-HuggingFace models combine per-token output vectors into a single document vector using a pooling strategy. The `pooling` field controls this behaviour:
+HuggingFace models combine per-token output vectors into a single document vector using a pooling strategy. The `pooling` field controls this behavior:
| Value | Behaviour |
+| Value | Behavior |As per coding guidelines: "Use American English spelling (e.g., analyze, behavior, color, ...)".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| HuggingFace models combine per-token output vectors into a single document vector using a pooling strategy. The `pooling` field controls this behaviour: | |
| | Value | Behaviour | | |
| |---|---| | |
| HuggingFace models combine per-token output vectors into a single document vector using a pooling strategy. The `pooling` field controls this behavior: | |
| | Value | Behavior | | |
| |---|---| |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@capabilities/hybrid_search/how_to/configure_huggingface_embedder.mdx` around
lines 74 - 77, Update the spelling of "behaviour" to American English "behavior"
in the text that describes HuggingFace model pooling; specifically change
occurrences around the `pooling` field label and the table header/description
where "Behaviour" appears so they read "Behavior".
Comment on lines
+186
to
+205
| Task cancellation is itself an asynchronous operation that creates a `taskCancelation` task. Because cancellation is an **atomic transaction**, either all matched tasks are successfully canceled, or none are. | ||
|
|
||
| <Warning> | ||
| **`POST /tasks/cancel` requires at least one filter.** To prevent users from accidentally canceling every enqueued and processing task, Meilisearch rejects unfiltered cancel requests with the [`missing_task_filters`](/reference/errors/error_codes#missing_task_filters) error. | ||
| </Warning> | ||
|
|
||
| You can also cancel `taskCancelation` tasks themselves as long as they are in the `enqueued` or `processing` state. This is possible because `taskCancelation` tasks are processed in **reverse order**: the last one you enqueue is processed first. | ||
|
|
||
| #### The `canceledBy` field | ||
|
|
||
| Every task object includes a `canceledBy` field: | ||
|
|
||
| - If the task was canceled, `canceledBy` contains the `uid` of the `taskCancelation` task that canceled it. | ||
| - If the task was not canceled, `canceledBy` is always `null`. | ||
|
|
||
| You can filter tasks by `canceledBy` in [the list tasks endpoint](/reference/api/tasks/list-tasks) to retrieve every task canceled by a given `taskCancelation`. | ||
|
|
||
| ### Deleting tasks | ||
|
|
||
| [Finished tasks](#task-status) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). | ||
| [Finished tasks](#task-status) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). Like cancellation, task deletion is an **atomic transaction**: either all matched tasks are successfully deleted, or none are. |
There was a problem hiding this comment.
Use "cancelation" instead of "cancellation" in prose.
Project style requires the single-l American form in narrative text. The API task type taskCancelation is correctly spelled with one l, but the surrounding prose uses "cancellation":
- Line 186: "Because cancellation is an atomic transaction"
- Line 205: "Like cancellation, task deletion..."
Keep the task-type identifier taskCancelation unchanged (it is an API value), but update the narrative words. As per coding guidelines: "Use American English spelling (e.g., analyze, behavior, color, center, license, canceled, cancelation, ...)".
✍️ Proposed fix
-Task cancellation is itself an asynchronous operation that creates a `taskCancelation` task. Because cancellation is an **atomic transaction**, either all matched tasks are successfully canceled, or none are.
+Task cancelation is itself an asynchronous operation that creates a `taskCancelation` task. Because cancelation is an **atomic transaction**, either all matched tasks are successfully canceled, or none are.
@@
-[Finished tasks](`#task-status`) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). Like cancellation, task deletion is an **atomic transaction**: either all matched tasks are successfully deleted, or none are.
+[Finished tasks](`#task-status`) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). Like cancelation, task deletion is an **atomic transaction**: either all matched tasks are successfully deleted, or none are.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Task cancellation is itself an asynchronous operation that creates a `taskCancelation` task. Because cancellation is an **atomic transaction**, either all matched tasks are successfully canceled, or none are. | |
| <Warning> | |
| **`POST /tasks/cancel` requires at least one filter.** To prevent users from accidentally canceling every enqueued and processing task, Meilisearch rejects unfiltered cancel requests with the [`missing_task_filters`](/reference/errors/error_codes#missing_task_filters) error. | |
| </Warning> | |
| You can also cancel `taskCancelation` tasks themselves as long as they are in the `enqueued` or `processing` state. This is possible because `taskCancelation` tasks are processed in **reverse order**: the last one you enqueue is processed first. | |
| #### The `canceledBy` field | |
| Every task object includes a `canceledBy` field: | |
| - If the task was canceled, `canceledBy` contains the `uid` of the `taskCancelation` task that canceled it. | |
| - If the task was not canceled, `canceledBy` is always `null`. | |
| You can filter tasks by `canceledBy` in [the list tasks endpoint](/reference/api/tasks/list-tasks) to retrieve every task canceled by a given `taskCancelation`. | |
| ### Deleting tasks | |
| [Finished tasks](#task-status) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). | |
| [Finished tasks](#task-status) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). Like cancellation, task deletion is an **atomic transaction**: either all matched tasks are successfully deleted, or none are. | |
| Task cancelation is itself an asynchronous operation that creates a `taskCancelation` task. Because cancelation is an **atomic transaction**, either all matched tasks are successfully canceled, or none are. | |
| <Warning> | |
| **`POST /tasks/cancel` requires at least one filter.** To prevent users from accidentally canceling every enqueued and processing task, Meilisearch rejects unfiltered cancel requests with the [`missing_task_filters`](/reference/errors/error_codes#missing_task_filters) error. | |
| </Warning> | |
| You can also cancel `taskCancelation` tasks themselves as long as they are in the `enqueued` or `processing` state. This is possible because `taskCancelation` tasks are processed in **reverse order**: the last one you enqueue is processed first. | |
| #### The `canceledBy` field | |
| Every task object includes a `canceledBy` field: | |
| - If the task was canceled, `canceledBy` contains the `uid` of the `taskCancelation` task that canceled it. | |
| - If the task was not canceled, `canceledBy` is always `null`. | |
| You can filter tasks by `canceledBy` in [the list tasks endpoint](/reference/api/tasks/list-tasks) to retrieve every task canceled by a given `taskCancelation`. | |
| ### Deleting tasks | |
| [Finished tasks](`#task-status`) remain visible in [the task list](/reference/api/tasks/list-tasks). To delete them manually, use the [delete tasks route](/reference/api/tasks/delete-tasks). Like cancelation, task deletion is an **atomic transaction**: either all matched tasks are successfully deleted, or none are. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@capabilities/indexing/tasks_and_batches/async_operations.mdx` around lines
186 - 205, Replace the prose instances of the British spelling "cancellation"
with the single-l American form "cancelation" while leaving the API identifier
taskCancelation unchanged; specifically update the sentence containing "Because
cancellation is an **atomic transaction**" and the sentence "Like cancellation,
task deletion..." to use "cancelation" so narrative text matches the project
style guide.
Comment on lines
+42
to
+44
| <Warning> | ||
| The value of `Authorization` headers is redacted in responses from `GET /webhooks` and `GET /webhooks/{uid}`. Do not use the redacted header values returned by Meilisearch when updating a webhook, or the webhook will start sending invalid credentials to your endpoint. Store the original secret on your side and resend it explicitly whenever you patch the webhook. | ||
| </Warning> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check the actual parameter name used in webhook endpoint references across the documentation.
# Search for webhook endpoint references to determine the consistent parameter naming convention
rg -n -C2 '/webhooks/\{' --type=md --type=jsonRepository: meilisearch/documentation
Length of output: 1204
🏁 Script executed:
# Search for webhook endpoint references in documentation files
rg -n '/webhooks/\{' resources/self_hosting/webhooks.mdxRepository: meilisearch/documentation
Length of output: 436
🏁 Script executed:
# Check if {uid} appears in webhook context in the documentation
rg -n '{uid}' resources/self_hosting/webhooks.mdxRepository: meilisearch/documentation
Length of output: 149
🏁 Script executed:
# Search all markdown documentation for webhook endpoint references
rg -n '/webhooks/\{.*\}' --type=mdRepository: meilisearch/documentation
Length of output: 51
🏁 Script executed:
# Check for {uid} anywhere in the webhooks documentation file to confirm all instances
rg 'uid' resources/self_hosting/webhooks.mdxRepository: meilisearch/documentation
Length of output: 1919
🏁 Script executed:
# Verify the OpenAPI spec parameter name one more time to be absolutely certain
rg -A5 'webhooks/\{uuid\}' assets/open-api/meilisearch-openapi.json | head -20Repository: meilisearch/documentation
Length of output: 193
Change endpoint parameter from {uid} to {uuid} to match the API specification.
The warning references GET /webhooks/{uid}, but the OpenAPI specification and navigation configuration both consistently use GET /webhooks/{uuid}. Update the endpoint parameter to {uuid} for accuracy.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@resources/self_hosting/webhooks.mdx` around lines 42 - 44, Update the
endpoint parameter in the Warning text from GET /webhooks/{uid} to GET
/webhooks/{uuid} so it matches the OpenAPI spec and navigation config; locate
the Warning block that currently contains "GET /webhooks/{uid}" and replace that
segment with "GET /webhooks/{uuid}" and verify the surrounding sentence remains
grammatically correct.
Registers five new curl snippets that demonstrate behaviors documented in the migration-gap restoration: - add_or_replace_documents_csv_1 / _ndjson_1: non-JSON content types - update_embedders_distribution_1: mean/sigma tuning - facet_search_exhaustive_1: exhaustiveFacetCount parameter - chat_patch_settings_prompts_1: tool prompt overrides
Contributor
|
Not sure who's meant to be tagged, so @curquiza let me know if you want me to take a look at this :) |
Member
Author
|
I'm asking mainly @Kerollmops to review because there is some infos that touch some Meilisearch's internal |
qdequele
changed the title
CaroFG
reviewed
Apr 23, 2026
CaroFG
requested changes
Apr 23, 2026
Co-authored-by: CaroFG <48251481+CaroFG@users.noreply.github.com>
There was a problem hiding this comment.
🧹 Nitpick comments (3)
snippets/generated-code-samples/code_samples_update_embedders_distribution_1.mdx (1)
5-5: Consider targeting/settings/embeddersfor consistency.The sibling
update_embedders_1sample in.code-samples.meilisearch.yaml(lines 586–597) targetsPATCH /indexes/{indexUid}/settings/embedders, while this new snippet patches the broader/settingsendpoint. Both endpoints acceptembedders, but the embedder-specific subroute matches the rest of the existing samples and is what/reference/api/settings_embeddersdocuments. Aligning them would make the example easier to copy alongside other embedder snippets.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@snippets/generated-code-samples/code_samples_update_embedders_distribution_1.mdx` at line 5, The PATCH example currently targets the generic settings endpoint; update the request path to the embedder-specific subroute so it matches the other sample and docs — change the HTTP target from PATCH 'MEILISEARCH_URL/indexes/INDEX_NAME/settings' to PATCH 'MEILISEARCH_URL/indexes/INDEX_NAME/settings/embedders' (the sample referenced as update_embedders_1 uses /settings/embedders), leaving the request body and surrounding metadata unchanged..code-samples.meilisearch.yaml (1)
598-614: Inconsistent endpoint andAuthorizationheader vs. sibling embedder sample.
update_embedders_distribution_1patches/indexes/INDEX_NAME/settingsand adds anAuthorizationheader, while the siblingupdate_embedders_1(lines 586–597) patches/indexes/INDEX_NAME/settings/embeddersand omits it. Per the settings reference, the embedder-specific subroute is the canonical example shape, and either both samples should include the auth header or neither should — the inconsistency is confusing when both snippets render on neighboring pages.📝 Suggested alignment
update_embedders_distribution_1: |- curl \ - -X PATCH 'MEILISEARCH_URL/indexes/INDEX_NAME/settings' \ + -X PATCH 'MEILISEARCH_URL/indexes/INDEX_NAME/settings/embedders' \ -H 'Content-Type: application/json' \ - -H 'Authorization: Bearer MEILISEARCH_KEY' \ --data-binary '{ - "embedders": { - "default": { - "source": "openAi", - "model": "text-embedding-3-small", - "distribution": { - "mean": 0.7, - "sigma": 0.3 - } - } + "default": { + "source": "openAi", + "model": "text-embedding-3-small", + "distribution": { + "mean": 0.7, + "sigma": 0.3 + } } }'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.code-samples.meilisearch.yaml around lines 598 - 614, The two curl samples are inconsistent: update_embedders_distribution_1 uses PATCH 'MEILISEARCH_URL/indexes/INDEX_NAME/settings' and includes an Authorization header, while the sibling update_embedders_1 patches '.../settings/embedders' and omits the header; align them by choosing the canonical embedder subroute and consistent auth usage—update update_embedders_distribution_1 (or update_embedders_1) so both target the same endpoint (prefer '/indexes/INDEX_NAME/settings/embedders') and either add the same '-H "Authorization: Bearer MEILISEARCH_KEY"' header to both samples or remove it from both for parity.capabilities/hybrid_search/advanced/tune_distribution.mdx (1)
26-26: Call out the composite-embedder caveat.
distributionis described as "compatible with all embedder sources", but for composite embedders it is only valid on the main (composite) embedder, not onindexingEmbedderorsearchEmbedder(seecapabilities/hybrid_search/advanced/composite_embedders.mdx). A one-line note or link from this page would prevent users from setting it in the wrong place.📝 Suggested addition
-`distribution` is an optional field compatible with all embedder sources. It is an object with two fields, both numbers between `0` and `1`: +`distribution` is an optional field compatible with all embedder sources. It is an object with two fields, both numbers between `0` and `1`. + +<Note> +For [composite embedders](/capabilities/hybrid_search/advanced/composite_embedders), declare `distribution` on the main embedder. It is not a valid field on `indexingEmbedder` or `searchEmbedder`. +</Note>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@capabilities/hybrid_search/advanced/tune_distribution.mdx` at line 26, Add a one-line caveat under the `distribution` description clarifying that while `distribution` is compatible with all embedder sources, for composite embedders it must be set on the composite (main) embedder only and not on `indexingEmbedder` or `searchEmbedder`, and include a brief link or pointer to the composite embedders documentation so readers know where to find the full explanation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.code-samples.meilisearch.yaml:
- Around line 598-614: The two curl samples are inconsistent:
update_embedders_distribution_1 uses PATCH
'MEILISEARCH_URL/indexes/INDEX_NAME/settings' and includes an Authorization
header, while the sibling update_embedders_1 patches '.../settings/embedders'
and omits the header; align them by choosing the canonical embedder subroute and
consistent auth usage—update update_embedders_distribution_1 (or
update_embedders_1) so both target the same endpoint (prefer
'/indexes/INDEX_NAME/settings/embedders') and either add the same '-H
"Authorization: Bearer MEILISEARCH_KEY"' header to both samples or remove it
from both for parity.
In `@capabilities/hybrid_search/advanced/tune_distribution.mdx`:
- Line 26: Add a one-line caveat under the `distribution` description clarifying
that while `distribution` is compatible with all embedder sources, for composite
embedders it must be set on the composite (main) embedder only and not on
`indexingEmbedder` or `searchEmbedder`, and include a brief link or pointer to
the composite embedders documentation so readers know where to find the full
explanation.
In
`@snippets/generated-code-samples/code_samples_update_embedders_distribution_1.mdx`:
- Line 5: The PATCH example currently targets the generic settings endpoint;
update the request path to the embedder-specific subroute so it matches the
other sample and docs — change the HTTP target from PATCH
'MEILISEARCH_URL/indexes/INDEX_NAME/settings' to PATCH
'MEILISEARCH_URL/indexes/INDEX_NAME/settings/embedders' (the sample referenced
as update_embedders_1 uses /settings/embedders), leaving the request body and
surrounding metadata unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1c747c0f-4eb1-43e9-9f3a-20d407c1d991
📒 Files selected for processing (14)
.code-samples.meilisearch.yamlcapabilities/conversational_search/getting_started/setup.mdxcapabilities/conversational_search/how_to/optimize_chat_prompts.mdxcapabilities/filtering_sorting_faceting/how_to/build_faceted_navigation.mdxcapabilities/filtering_sorting_faceting/how_to/facet_search.mdxcapabilities/hybrid_search/advanced/tune_distribution.mdxcapabilities/indexing/how_to/add_and_update_documents.mdxsnippets/generated-code-samples/code_samples_add_or_replace_documents_csv_1.mdxsnippets/generated-code-samples/code_samples_add_or_replace_documents_ndjson_1.mdxsnippets/generated-code-samples/code_samples_chat_patch_settings_prompts_1.mdxsnippets/generated-code-samples/code_samples_facet_search_exhaustive_1.mdxsnippets/generated-code-samples/code_samples_get_documents_post_with_filter_1.mdxsnippets/generated-code-samples/code_samples_update_embedders_distribution_1.mdxsnippets/generated-code-samples/code_samples_update_faceting_settings_max_values_per_facet_1.mdx
✅ Files skipped from review due to trivial changes (7)
- snippets/generated-code-samples/code_samples_add_or_replace_documents_ndjson_1.mdx
- snippets/generated-code-samples/code_samples_update_faceting_settings_max_values_per_facet_1.mdx
- snippets/generated-code-samples/code_samples_facet_search_exhaustive_1.mdx
- snippets/generated-code-samples/code_samples_add_or_replace_documents_csv_1.mdx
- snippets/generated-code-samples/code_samples_get_documents_post_with_filter_1.mdx
- snippets/generated-code-samples/code_samples_chat_patch_settings_prompts_1.mdx
- capabilities/filtering_sorting_faceting/how_to/facet_search.mdx
🚧 Files skipped from review as they are similar to previous changes (2)
- capabilities/indexing/how_to/add_and_update_documents.mdx
- capabilities/conversational_search/how_to/optimize_chat_prompts.mdx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Restores 87 granular documentation details that existed in the old per-endpoint reference docs (
/reference/api/*.mdx,/reference/errors/*.mdx) and were dropped when those pages were replaced by OpenAPI-rendered references. These aren't missing features, they're the prose warnings, defaults, semantics, incompatibilities, and gotchas that the OpenAPI spec doesn't naturally carry.facet_search,configure_dictionary,tune_distribution<Note>,<Warning>,<Tip>), reference tables, and inline prose on existing capability pagesconfig/navigation.jsonto surface the 3 new pagesScope by section:
_vectors_vectorsobject shape,regeneratesemantics, pooling/revision for HF, composite constraints, field incompatibility matrix,distributiontuningGET /searchdiscouragement, string-only filters, highlight scopeGET /documentsdiscouragement, filter requirement, CSV content-type rulebatchUidfieldDistributionscopeattributesToSearchOn,facetStats,localesprecedence, etc.detailsshape, 1M-cap auto-cleanup, termination safetyAll additions respect the project writing rules (no em dashes, no Co-Authored-By, cloud-first examples, Mintlify callout components).
Test plan
config/navigation.jsonsurfaces the three new pages in the Mintlify sidebarSummary by CodeRabbit