fix: validate Meilisearch provider readiness - #1102
Conversation
📝 WalkthroughWalkthrough
Changes
Sequence Diagram(s)sequenceDiagram
participant 호출자
participant MeilisearchEngine
participant validateMeilisearchOptions
participant MeiliSearch SDK
participant normalizeMeilisearchError
호출자->>MeilisearchEngine: indexDocument(indexName, doc)
MeilisearchEngine->>validateMeilisearchOptions: options 검증
validateMeilisearchOptions-->>MeilisearchEngine: MeilisearchEngineOptions 반환 (또는 Problem throw)
MeilisearchEngine->>MeilisearchEngine: validateIndexName, validateDocument
MeilisearchEngine->>MeiliSearch SDK: runOperation → addDocuments([{...doc, _tenantId}])
MeiliSearch SDK-->>MeilisearchEngine: EnqueuedTask {taskUid}
MeilisearchEngine->>MeiliSearch SDK: waitForTask(taskUid)
MeiliSearch SDK-->>MeilisearchEngine: Task {status}
alt status === "failed"
MeilisearchEngine->>normalizeMeilisearchError: task.error
normalizeMeilisearchError-->>호출자: Problem throw
else SDK 예외 발생
MeilisearchEngine->>normalizeMeilisearchError: caught error + context
normalizeMeilisearchError-->>호출자: Problem throw
end
MeilisearchEngine-->>호출자: 성공
sequenceDiagram
participant 운영자
participant MeilisearchDiagnosticsProvider
participant validateMeilisearchOptions
participant MeiliSearch SDK
participant readinessCheck
운영자->>MeilisearchDiagnosticsProvider: getHealth(signal?)
MeilisearchDiagnosticsProvider->>validateMeilisearchOptions: config 검증
alt 설정 누락
validateMeilisearchOptions-->>MeilisearchDiagnosticsProvider: Problem throw
MeilisearchDiagnosticsProvider-->>운영자: HealthStatus{status:"unhealthy", problemCode:"missing-config"}
else readinessCheck 미설정
MeilisearchDiagnosticsProvider-->>운영자: HealthStatus{status:"healthy", liveCheck:"not_configured"}
else readinessCheck 설정됨
MeilisearchDiagnosticsProvider->>MeiliSearch SDK: new MeiliSearch(config)
MeilisearchDiagnosticsProvider->>readinessCheck: readinessCheck({client, config, signal})
readinessCheck-->>MeilisearchDiagnosticsProvider: MeilisearchReadinessCheckResult | void
MeilisearchDiagnosticsProvider->>MeilisearchDiagnosticsProvider: sanitizeDiagnosticValue(details)
MeilisearchDiagnosticsProvider-->>운영자: HealthStatus{status:"healthy", liveCheck:"passed"}
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
📊 Benchmark Results❌ Some benchmarks failed Gate failures
Updated: 2026-06-29T13:08:21.354Z · Commit: 9350355 |
e16031b to
a2e5505
Compare
There was a problem hiding this comment.
Actionable comments posted: 11
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/search-meilisearch/src/tests/MeilisearchEngine.spec.ts (1)
203-255: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
_tenantId예약 필드 경로도 같이 잠가야 합니다.이 구간은
tenantId충돌만 막지만, 현재MeilisearchEngine.transformFilters()는tenantId만 특수 처리하고_tenantId는 일반 필드로 통과시킵니다. 그러면 호출자가 provider-owned 필드를 직접 넣어도 테스트가 놓치고, PR 목표인 deterministic provider-owned filter fields 계약도 보장되지 않습니다._tenantId입력을 명시적으로 거부하거나 무시하는 케이스를 추가해 두는 게 좋습니다.회귀를 막는 테스트 예시
await expect( engine.search("index", { query: "test", filters: { tenantId: "tenant-2" }, }), ).rejects.toThrow(MeilisearchInvalidRequestProblem); + await expect( + engine.search("index", { + query: "test", + filters: { _tenantId: "tenant-2" }, + }), + ).rejects.toThrow(MeilisearchInvalidRequestProblem); expect(mocks.indexMock.search).not.toHaveBeenCalled();🤖 Prompt for 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. In `@packages/search-meilisearch/src/tests/MeilisearchEngine.spec.ts` around lines 203 - 255, The filter validation in MeilisearchEngine needs to block the reserved provider-owned field _tenantId, not just tenantId conflicts. Update MeilisearchEngine.transformFilters() (and any related filter sanitization path) so direct _tenantId input is explicitly rejected or ignored before building the search request. Add/adjust tests in MeilisearchEngine.spec.ts alongside the tenant filter cases to cover _tenantId being passed in filters and verify MeilisearchEngine.search does not call indexMock.search for that input.
🤖 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
`@packages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchIndexNotFoundProblem.md`:
- Line 8: Update the class description in MeilisearchIndexNotFoundProblem so it
no longer says it exports a tenant-token-related Problem. This is a copied
description from TenantTokenNotConfiguredProblem; replace it with wording that
matches the class name and purpose, describing that it represents the Problem
thrown when the requested Meilisearch index cannot be found.
In
`@packages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchInvalidRequestProblem.md`:
- Line 8: The class description for MeilisearchInvalidRequestProblem is
incorrect and currently describes tenant token setup instead of request
validation failures. Update the markdown description in the
MeilisearchInvalidRequestProblem documentation so it matches the class purpose,
using the MeilisearchInvalidRequestProblem symbol as the target reference, and
rewrite it to describe a Problem emitted when Meilisearch request validation
fails.
In
`@packages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchRetryableUpstreamProblem.md`:
- Line 8: The class description for MeilisearchRetryableUpstreamProblem is
incorrect and describes tenant token setup instead of the actual retryable
upstream error behavior. Update the markdown summary for
MeilisearchRetryableUpstreamProblem to match its purpose as a Problem
representing retryable Meilisearch upstream failures, and keep the wording
consistent with the class name and related API docs.
In
`@packages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchTerminalUpstreamProblem.md`:
- Line 8: The class description for MeilisearchTerminalUpstreamProblem is
incorrect and currently mentions tenant token settings instead of the actual
purpose. Update the documentation text in MeilisearchTerminalUpstreamProblem to
describe that it represents a non-retryable Meilisearch upstream terminal
error/problem, and ensure the class summary matches the intended meaning used by
the Problem definition.
In
`@packages/docs/src/content/docs/api/search-meilisearch/src/classes/MissingMeilisearchConfigProblem.md`:
- Line 8: The class description for MissingMeilisearchConfigProblem is incorrect
and currently mentions tenant token settings instead of missing Meilisearch
configuration. Update the documentation text in
MissingMeilisearchConfigProblem.md to describe that this Problem represents
missing Meilisearch config, keeping the wording aligned with the class name and
purpose.
In
`@packages/docs/src/content/docs/api/search-meilisearch/src/functions/isRetryableMeilisearchError.md`:
- Line 10: The description for isRetryableMeilisearchError is copied from
tenant-token docs and does not match the function’s behavior. Update the
markdown summary for isRetryableMeilisearchError to describe that it determines
whether a Meilisearch error is retryable, and remove any tenant token or
Problem-related wording. Keep the wording aligned with the function name and its
actual purpose.
In
`@packages/docs/src/content/docs/api/search-meilisearch/src/functions/normalizeMeilisearchError.md`:
- Line 10: The `normalizeMeilisearchError` function documentation contains a
copied tenant-token description that does not match its actual purpose. Update
the doc text in the `normalizeMeilisearchError` markdown to describe that it
normalizes Meilisearch errors into a Problem, and make sure the wording aligns
with the function name and behavior rather than tenant token setup.
In `@packages/search-meilisearch/src/libs/MeilisearchDiagnosticsProvider.ts`:
- Around line 160-168: The string-based redaction in redactDiagnosticText and
the object-key redaction via SENSITIVE_DIAGNOSTIC_KEY are using different
sensitive-field sets, so align them to share the same keys. Update the
diagnostic redaction logic so both structured values and free-form text redact
the same sensitive identifiers, including cookie-related fields as well as
token/access key variants, and make sure any helper/constants used by
Meilisearch diagnostics stay in sync.
In `@packages/search-meilisearch/src/libs/MeilisearchEngine.ts`:
- Around line 310-317: The waitForTask flow in MeilisearchEngine currently
treats taskUid === undefined as success by returning early, which can hide
malformed task responses. Update waitForTask to distinguish between task wait
being disabled and a missing task UID: only skip waiting when
this.options.taskWait?.enabled === false, and when task wait is enabled but
getTaskUid(task) returns undefined, fail the operation as a Problem/error with
the existing operation/context details so indexing/deletion does not incorrectly
succeed.
- Around line 75-104: `MeilisearchEngine.indexDocument` and
`MeilisearchEngine.bulkIndex` only inject `_tenantId`, so the stored
`SearchDocument.tenantId` can remain stale and leak the wrong tenant in search
results. Update the document payloads in these methods to keep `tenantId`
aligned with the active tenant returned by `getTenantId(...)`, alongside
`_tenantId`, before calling `index.addDocuments`; keep the validation and task
flow unchanged.
In `@packages/search-meilisearch/src/tests/MeilisearchProblems.spec.ts`:
- Around line 92-106: The timeout test in isRetryableMeilisearchError is
currently passing via message fallback instead of the error.name branch. Update
the test in MeilisearchProblems.spec.ts so the MeiliSearchTimeOutError case uses
a neutral message and only verifies the name-based retryable mapping, keeping
the MeiliSearchRequestError assertion separate and similarly explicit.
---
Outside diff comments:
In `@packages/search-meilisearch/src/tests/MeilisearchEngine.spec.ts`:
- Around line 203-255: The filter validation in MeilisearchEngine needs to block
the reserved provider-owned field _tenantId, not just tenantId conflicts. Update
MeilisearchEngine.transformFilters() (and any related filter sanitization path)
so direct _tenantId input is explicitly rejected or ignored before building the
search request. Add/adjust tests in MeilisearchEngine.spec.ts alongside the
tenant filter cases to cover _tenantId being passed in filters and verify
MeilisearchEngine.search does not call indexMock.search for that input.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 6b6b20e5-a45b-4ee1-9cf4-21e94cb0c9d4
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (40)
.changeset/search-meilisearch-readiness.mdREADME.mddocs/package-catalog.jsondocs/package-docs-report.mddocs/problem-code-registry.jsonpackages/docs/src/content/docs/api/problems-core/src/classes/Problem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchDiagnosticsProvider.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchEngine.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchIndexNotFoundProblem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchInvalidRequestProblem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchRetryableUpstreamProblem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MeilisearchTerminalUpstreamProblem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/MissingMeilisearchConfigProblem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/classes/TenantTokenNotConfiguredProblem.mdpackages/docs/src/content/docs/api/search-meilisearch/src/functions/isRetryableMeilisearchError.mdpackages/docs/src/content/docs/api/search-meilisearch/src/functions/normalizeMeilisearchError.mdpackages/docs/src/content/docs/api/search-meilisearch/src/type-aliases/MeilisearchDiagnosticsOptions.mdpackages/docs/src/content/docs/api/search-meilisearch/src/type-aliases/MeilisearchEngineOptions.mdpackages/docs/src/content/docs/api/search-meilisearch/src/type-aliases/MeilisearchReadinessCheckContext.mdpackages/docs/src/content/docs/api/search-meilisearch/src/type-aliases/MeilisearchReadinessCheckResult.mdpackages/docs/src/content/docs/api/search-meilisearch/src/type-aliases/MeilisearchTaskWaitOptions.mdpackages/docs/src/content/docs/api/search-meilisearch/src/type-aliases/TenantTokenOptions.mdpackages/docs/src/content/docs/en/reference/extension-matrix.mdpackages/docs/src/content/docs/en/reference/problem-recovery-cookbook.mdpackages/docs/src/content/docs/en/reference/provider-maturity.mdpackages/search-meilisearch/README.mdpackages/search-meilisearch/package.jsonpackages/search-meilisearch/src/index.tspackages/search-meilisearch/src/libs/MeilisearchConfig.tspackages/search-meilisearch/src/libs/MeilisearchDiagnosticsProvider.tspackages/search-meilisearch/src/libs/MeilisearchEngine.tspackages/search-meilisearch/src/libs/problems/MeilisearchProblems.tspackages/search-meilisearch/src/libs/types.tspackages/search-meilisearch/src/tests/MeilisearchDiagnosticsProvider.spec.tspackages/search-meilisearch/src/tests/MeilisearchEngine.spec.tspackages/search-meilisearch/src/tests/MeilisearchLiveSmoke.spec.tspackages/search-meilisearch/src/tests/MeilisearchProblems.spec.tspackages/search-meilisearch/tsconfig.jsonpackages/search-meilisearch/vitest.config.tspublic-api-surface.snapshot.json
a2e5505 to
9573af9
Compare
Fixes #945.
Summary
@croco/search-meilisearchwith validated configuration, stable Problem mapping, safe task waiting, tenant-isolated filtering, and deterministic provider-owned filter fields.@croco/search-meilisearchto beta in the package catalog with documented readiness evidence.Verification
corepack pnpm --filter @croco/search-meilisearch test- passed, 35 tests / 1 skipped live smoke.corepack pnpm --filter @croco/search-meilisearch typecheck- passed.corepack pnpm --filter @croco/search-meilisearch build- passed.corepack pnpm --filter @croco/search-meilisearch lint- passed.corepack pnpm --filter @croco/docs docs:build- passed.corepack pnpm package-manifests:check- passed.corepack pnpm docs:catalog:check- passed.corepack pnpm public-api:check- passed.corepack pnpm problem-registry:check- passed.corepack pnpm docs:api-triggers:check- passed.corepack pnpm --filter @croco/search-core test- passed, 76 tests.corepack pnpm changeset-required:check -- --base origin/trunk --head HEAD- passed.corepack pnpm exec oxfmt --check ...- passed for changed Markdown/generated docs.git diff --checkandgit diff --cached --check- passed.COREPACK_ENABLE_DOWNLOAD_PROMPT=0 npx -y pnpm@10.15.1 check- passed.Review Gates
_tenantIdrejection, tenant conflict rejection, task waiting, malformed task responses, safe filter/sort validation, upstream Problem normalization, and live smoke behavior behind explicit Meilisearch credentials.@croco/diagnostics-coreis declared in the package manifest and lockfile, and a patch changeset is included.Notes
--no-verifybecause the lefthookpnpminvocation prompts for an interactivenode_modulesreinstall in this worktree. The equivalent staged formatter/linter commands and the validation checks above passed manually.MEILISEARCH_HOSTandMEILISEARCH_API_KEYare set.Risk
Low-medium. The provider now fails invalid config, unsafe filters, malformed task responses, and upstream failures explicitly through stable Problems, so callers that depended on implicit SDK behavior may need to handle those typed failures.