feat: add Dynamic Search Rules endpoints (#495) - #497
Conversation
Add SDK support for the experimental Dynamic Search Rules API introduced
in Meilisearch v1.50.0. The endpoints require the `dynamicSearchRules`
experimental feature flag to be enabled on the server.
New client methods on `MeiliSearchClient`:
- `listDynamicSearchRules({params})` -> Result<DynamicSearchRule>
- `getDynamicSearchRule(uid)` -> DynamicSearchRule
- `updateOrCreateDynamicSearchRule(uid, rule)` -> Task (async)
- `deleteDynamicSearchRule(uid)` -> Task (async)
Design notes:
- `DynamicSearchRule.conditions` and `.actions` are exposed as raw
maps/lists so the SDK keeps working when the server adds sub-fields
without a coordinated SDK release. Consumers wanting strongly typed
access can wrap them at their layer.
- `toUpsertBody()` is sparse (nulls omitted) so PATCH acts as a real
partial upsert.
- `DynamicSearchRulesQuery` mirrors the same sparse-body pattern for
`POST /dynamic-search-rules`.
Tests: 9 serialization / query-body unit tests covering full-response
parsing, sparse responses, unparseable timestamps, and body-shape
round-tripping. Integration tests are intentionally not added: the
endpoints are experimental and require a server-side feature flag toggle
that isn't in the current test setup.
Code samples `list_dynamic_search_rules_1`, `get_dynamic_search_rule_1`,
`patch_dynamic_search_rule_1`, `delete_dynamic_search_rule_1` added to
`.code-samples.meilisearch.yaml` matching the keys used by the
Meilisearch documentation site.
|
Warning Review limit reached
Next review available in: 26 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds experimental Dynamic Search Rules support to the Dart client, including public models, query serialization, four API endpoints, async task handling, serialization tests, and usage examples. ChangesDynamic Search Rules
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant DartClient
participant MeilisearchAPI
participant TaskQueue
DartClient->>MeilisearchAPI: List or retrieve a dynamic rule
MeilisearchAPI-->>DartClient: DynamicSearchRule response
DartClient->>MeilisearchAPI: Upsert or delete a dynamic rule
MeilisearchAPI->>TaskQueue: Create asynchronous task
TaskQueue-->>DartClient: Task response
Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/src/query_parameters/dynamic_search_rules_query.dart`:
- Around line 13-15: The DynamicSearchRulesQuery filter must be a structured
nullable raw map rather than a string expression. Update the filter field and
its serialization in dynamic_search_rules_query.dart to preserve and emit the
map unchanged when present, and update
test/dynamic_search_rules_serialization_test.dart to use a valid structured
filter fixture such as query/active or attributePatterns/active.
In `@lib/src/results/dynamic_search_rule.dart`:
- Line 18: Rename DynamicSearchRule.priority to precedence throughout the model,
clarify its documentation to state that lower values are processed first, and
update fromJson and toUpsertBody to read and serialize the precedence field
instead of priority.
🪄 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 Plus
Run ID: c88e66a1-5252-43fe-a4fe-8372c1a742b6
📒 Files selected for processing (7)
.code-samples.meilisearch.yamllib/src/client.dartlib/src/query_parameters/_exports.dartlib/src/query_parameters/dynamic_search_rules_query.dartlib/src/results/_exports.dartlib/src/results/dynamic_search_rule.darttest/dynamic_search_rules_serialization_test.dart
Two review findings from CodeRabbit on meilisearch#497: 1. Rename `priority` to `precedence` on DynamicSearchRule. Meilisearch v1.50.0 renamed the ordering field and rejects the old `priority` key on the wire. Lower numeric `precedence` values are applied first (rule with precedence: 1 wins over precedence: 5). Updates the field name, KDoc, fromJson lookup, and toUpsertBody emission accordingly. 2. Change `DynamicSearchRulesQuery.filter` from a bare filter-string to a structured DynamicSearchRulesFilter object. In v1.50.0 the list endpoint filter is an object with `query` (free-text search across description + conditions.query.words) and `active` (bool status filter), not a filter-expression string. toBody() drops an entirely empty filter object so unconfigured queries don't send {} on the wire. Tests updated: precedence round-trip, structured filter round-trip, empty-filter drop, sparse-filter emission. `.code-samples.meilisearch.yaml` patch sample uses `precedence`.
|
Thanks @coderabbitai — both findings addressed in 1. 2. Tests + |
|
Tip For best results, initiate chat on the files or code changes.
🐇✨ ✏️ Learnings added
If you found this review helpful, would you consider giving us a shout-out on X? Thank you for using CodeRabbit! |
|
I've pushed fixes for both of CodeRabbit's points (the @curquiza when you get a chance, could this get a review? Happy to make any changes needed. |
1 participant
Fixes #495.
Summary
Adds SDK support for the experimental Dynamic Search Rules API introduced in Meilisearch v1.50.0. The endpoints require the
dynamicSearchRulesexperimental feature flag to be enabled on the server:New client methods on
MeiliSearchClientPOST /dynamic-search-ruleslistDynamicSearchRules({params})Result<DynamicSearchRule>GET /dynamic-search-rules/{uid}getDynamicSearchRule(uid)DynamicSearchRulePATCH /dynamic-search-rules/{uid}updateOrCreateDynamicSearchRule(uid, rule)Task(async)DELETE /dynamic-search-rules/{uid}deleteDynamicSearchRule(uid)Task(async)All four are annotated with
@RequiredMeiliServerVersion('1.50.0').Design notes
DynamicSearchRule.conditionsand.actionsare exposed as rawMap<String, Object?>/List<Map<String, Object?>>rather than fully typed sub-models. The rule schema is young and still evolving on the server side; keeping these fields raw means the SDK keeps working when the server adds sub-fields without a coordinated SDK release. Consumers that want strongly typed access can wrap them at their layer.DynamicSearchRule.toUpsertBody()is sparse (nulls omitted) so the PATCH endpoint acts as a true partial upsert.DynamicSearchRulesQuery.toBody()mirrors the same sparse-body pattern for the POST list endpoint.Tests
9 unit tests in
test/dynamic_search_rules_serialization_test.dart:conditionsandactions)uidpresent)toUpsertBodysparse behavior + verbatim conditions/actionsDynamicSearchRulesQuery.toBodyempty / full / sparse round-tripIntegration tests against a live Meilisearch are intentionally not added: the endpoints are experimental and require a server-side feature flag toggle that isn't in the current test-suite setup. Happy to add them in a follow-up once the flag is wired into the CI setup, or as part of this PR if there's guidance on the preferred approach.
Code samples
Added the four keys the documentation site expects to
.code-samples.meilisearch.yaml:list_dynamic_search_rules_1get_dynamic_search_rule_1patch_dynamic_search_rule_1delete_dynamic_search_rule_1Sample bodies mirror the equivalent curl samples in meilisearch/documentation.
Verification
dart test test/dynamic_search_rules_serialization_test.dart— 9/9 passdart analyze— clean on all touched filesSummary by CodeRabbit
New Features
Tests