Repository navigation
bug(registry): meilisearch block is not 2.2-ready (removed seller link, middlewares shape, client pin, types, index orphans) #975
Description
Summary
The meilisearch registry block targets the 2.1.x data model and breaks on
a 2.2 project in several independent ways.
Environment
@mercurjs/core 2.2.0-canary.11 (also checked the canary.12 diff — the
block is unchanged), Medusa 2.13.4, block installed from the official
registry into a fresh basic project (bun).
Issues
1. Uses the removed product ↔ seller link
The sync subscriber/utils query product.seller.* via query.graph. On
2.2 the link no longer exists (sellers attach to variants through offers):
Entity 'Product' does not have property 'seller'
Every product sync fails. The store search route also hard-filters by
seller.status = "active" and hydrates seller.* — same failure.
2. middlewares.ts shape is not consumable
The block ships a middlewares file exporting a plain array, while Medusa
expects a default export of defineMiddlewares({ routes }). Result: the
search route's Zod validation never registers and the handler crashes on
validatedBody being undefined. Needs a defineMiddlewares wrapper (or
documentation that the consumer must merge it into their own
src/api/middlewares.ts).
3. Incompatible with current meilisearch npm client
With meilisearch@0.58 (resolved by ^ at install time) the service
throws MeiliSearch is not a constructor. Works with ^0.46. The block
should pin a known-good client range.
4. service.ts does not pass type-check
search() reads page / totalPages / hitsPerPage / totalHits from
SearchResponse, but in the client's types those fields exist only on the
paginated variant of the response union. medusa develop doesn't
type-check so it appears to work; the first medusa build fails with
TS2339.
5. Hard-deleted products stay in the index forever
The sync workflow removes unpublished products but never reconciles
documents whose DB row was hard-deleted (e.g. after a reseed). A
listAllIds-style reconciliation pass in the sync workflow fixes it
(we have a working implementation and can PR it).
Workarounds deployed in our project
All five patched locally and tracked in our UPSTREAM registry; happy to
turn any of them into PRs.
Activity
fix(registry): make meilisearch block 2.2-ready
fix(registry): make meilisearch block 2.2-ready
fix(registry): make meilisearch block 2.2-ready
fix(registry): make meilisearch block 2.2-ready (#1048)
vholik commentedon Jun 22, 2026
Thanks for the detailed write-up — really helpful, and great catches.
Most of this is now fixed and merged in #1048:
product ↔ sellerlink — on 2.2 the link is exposed as the pluralproduct.sellers(a many-to-many list). The block now queriessellers.*and flattens to a singleselleron the index document, and also filters on the liveseller.status = "open"(the old"active"was never a valid status).middlewares.tsshape — the file now default-exportsdefineMiddlewares({ routes })alongside the namedallMeilisearchMiddlewaresarray, andPLUGIN.mddocuments merging it into your ownsrc/api/middlewares.ts.meilisearch@^0.47.0in the registry manifest so the CLI stops resolving the incompatible0.58.service.tstype-check — the pagination fields are now read through an optional view, somedusa buildno longer fails with TS2339.That leaves #5 (hard-deleted index orphan reconciliation), which I left out of this PR. Since you mentioned you already have a working
listAllIds-style implementation — a PR would be very welcome and I'll happily review it. 🙏