Meilisearch Index Sync
Keep a Meilisearch index current so search, filters, and sorting reflect the live data.
What it adds
A background sync that mirrors app records into a Meilisearch index, with attribute configuration, batched updates, and a swap-based rebuild.
What your agent is told to do
5
What your agent is told to do
5-
1
Declare the searchable, filterable, and sortable attributes as configuration that is applied before the first query relies on them, and re-apply it as part of deploy or rebuild. An attribute that is queried but not configured will silently return nothing useful.
-
2
Batch changes through the app's existing background-job system and treat every write as asynchronous: record the task the engine returns, poll it to completion, and only mark the record synced once the engine confirms it. Do not assume a successful submission means the document is queryable.
-
3
Compose the tenant and permission constraint on the server for every search and never merge a filter expression supplied by the client. A user who can inject a filter clause can read outside their workspace.
-
4
Perform schema and attribute changes by indexing into a second index and swapping it into place once it is fully populated, so queries are never served by a half-built index.
-
5
Typesense Index Sync is the same feature for a different engine, and the surrounding search UI, ranking, and result rendering belong to the app's existing search screens. This brief owns only the pipeline from record to index; do not rebuild the search interface here.
Edge cases it handles
8
Edge cases it handles
8- Queries that filter or sort on an attribute the index was never configured for return misleading results rather than an error, so verify the attribute configuration at boot and fail loudly when it drifts from what the code expects.
- Tenant isolation has to live outside anything the user controls. Filters assembled from query parameters, or passed straight through from the browser, are the standard way this leaks across customers.
- Because updates are processed asynchronously, a user who saves and immediately searches may not see their own change. Track the engine's task state, retry the ones that fail, and surface a short indexing delay rather than pretending the write was instant.
- Deletes and permission changes must remove documents, not merely stop linking to them. A record that is unshared, archived, or soft-deleted while its index entry survives is still discoverable by title and snippet.
- Schema changes must be zero-downtime: build the replacement index alongside the live one, verify counts and sample queries, then swap, keeping the old index available to swap back.
- Batches that exceed the engine's payload or document size limits must be split, and a single oversized document must be truncated or skipped with a logged reason instead of failing its whole batch.
- Rate limiting and a queue backlog after an outage need bounded retries with exponential backoff and jitter, plus a dead-letter path for documents that fail repeatedly.
- When the engine is down, degrade to a database-backed query with a visible notice about reduced result quality. An empty page reads to the user as an absence of data.
Definition of done
9
Definition of done
9- Searchable, filterable, and sortable attributes are configured declaratively and verified before queries depend on them.
- Record changes reach the index through background jobs whose asynchronous tasks are tracked to completion.
- Tenant scoping is enforced server-side and no client-supplied filter expression reaches the engine.
- Deleted records and records the user has lost access to disappear from results promptly.
- An index rebuild or schema change swaps in without search downtime and can be reverted.
- Failed and oversized documents land in a dead-letter path with a reason instead of blocking the queue.
- An engine outage degrades to database search with an explicit notice rather than an empty state.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Contentful Entry Sync
Contentful Entry Sync
Create and update Contentful entries against the connected space, environment, and locale.
What it does
A sync that writes app records into Contentful entries using the connected space's content model and locale configuration.
How it works
- 1 Have the operator select the space, the environment, and the default locale during connection, and store all three, because writing production content into a sandbox environment is an easy and expensive mistake.
- 2 Fetch the content model at connection time and again before each sync run, map app fields to entry fields by their stable identifiers, and validate the value type against the model before attempting the write.
- 3 Write every localized field under an explicit locale rather than relying on whatever the space treats as default, and state clearly which locales the app owns and which it leaves to editors.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/contentful-entry-sync
Typesense Index Sync
Typesense Index Sync
Keep a search index in step with your records so results stay current and correctly scoped.
What it does
A one-way sync from the app's records into a Typesense collection, with server-enforced tenant filtering and a rebuild path.
How it works
- 1 Identify every model users search today and declare the indexed shape explicitly: the fields people type into, the fields they filter and sort on, and nothing more. Treat a missing or newly added field as absent rather than letting the document fail validation.
- 2 Reuse the app's existing background-job system to push creates, updates, and deletes. Do not index inside the request cycle; a slow or unreachable search service must never make a save fail or hang.
- 3 Build the tenant, workspace, and permission filter on the server at query time and attach it to every search. Do not accept a filter, collection name, or scope value from a client-supplied parameter, because anything the browser can set the browser can change.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/typesense-index-sync
Algolia Index Sync
Algolia Index Sync
Keep the search index matching the database, including who is allowed to see what.
What it does
A sync pipeline that mirrors records into a search index with tenant-scoped filters and scheduled reconciliation.
How it works
- 1 Identify every record type that should be searchable and define one index document per record, keyed by an identifier that never changes for the life of that record.
- 2 Push changes through the app's existing background-job system on create, update, and delete, and make every write idempotent so a replayed job produces the same document rather than a duplicate.
- 3 Put tenant, workspace, and visibility values on each document as filter attributes, and have the server issue short-lived scoped search credentials that pin those filters. The browser must never choose its own filter.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/algolia-index-sync
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.