starred/karakeep

Fork 0

mirror of https://github.com/karakeep-app/karakeep.git synced 2026-04-26 08:26:03 +03:00

[GH-ISSUE #1445] Meilisearch crashed, search fails after reindex with error: userId not filterable #916

New issue

Closed

opened 2026-03-02 11:53:44 +03:00 by kerem · 2 comments

kerem commented

2026-03-02 11:53:44 +03:00

Owner

Originally created by @jk on GitHub (May 21, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1445

Describe the Bug

After reindexing Meilisearch due to corrupted data files, search requests now fail with a 400 error. The error message indicates that userId is not a filterable attribute, although the frontend appears to rely on it for filtering.

Steps to Reproduce

Read Troubleshooting Guide: Upgrading Meilisearch - Migrating the Meilisearch db version
Noticed missing search results for newly added bookmarks.
Checked Meilisearch logs and found:

ERROR file_store: Can't access update file cdcea004-1007-41b2-b670-303323994fcf: No such file or directory (os error 2)
ERROR index_scheduler: No such file or directory (os error 2)

Stopped and removed the Meilisearch container.
Deleted the old data volume.
Recreated the container with a fresh volume.
Triggered a full reindex via the admin interface (successfully).
Performed a search → received “Something went wrong” message.
Meilisearch logs show:

WARN HTTP request{method=POST host="meilisearch:7700" route=/indexes/bookmarks/search query_parameters= user_agent=node status_code=400 error=Index `bookmarks`: Attribute `userId` is not filterable. This index does not have configured filterable attributes.

Expected Behaviour

Search results should work after reindexing, especially for filters used by the UI like userId.

Screenshots or Additional Context

I am the only user in the system.
I’m using Pocket ID as the OIDC provider.
Content of .env:

DATA_DIR=/data
MEILI_ADDR: http://meilisearch:7700
MEILI_MASTER_KEY=[redacted]
NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=[redacted]
BROWSER_WEB_URL: http://chrome:9222
OPENAI_API_KEY: [redacted]
NEXTAUTH_URL: "https://karakeep.[redacted]"
DISABLE_SIGNUPS: "false"
DISABLE_PASSWORD_AUTH: "true"
OAUTH_ALLOW_DANGEROUS_EMAIL_ACCOUNT_LINKING: "true"
OAUTH_PROVIDER_NAME: "Pocket ID"
OAUTH_SCOPE: "openid email profile groups"
OAUTH_CLIENT_ID: [redacted]
OAUTH_CLIENT_SECRET: [redacted]
OAUTH_WELLKNOWN_URL: https://auth.[redacted]/.well-known/openid-configuration
INFERENCE_LANG: english
OCR_LANGS: "deu,eng"
TZ: "Europe/Berlin"

Device Details

Google Chrome 136.0.7103.114 on macOS 15.5

Exact Karakeep Version

v0.24.1

Have you checked the troubleshooting guide?

I have checked the troubleshooting guide and I haven't found a solution to my problem

Originally created by @jk on GitHub (May 21, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1445 ### Describe the Bug After reindexing Meilisearch due to corrupted data files, search requests now fail with a 400 error. The error message indicates that userId is not a filterable attribute, although the frontend appears to rely on it for filtering. ### Steps to Reproduce 0. Read [Troubleshooting Guide: Upgrading Meilisearch - Migrating the Meilisearch db version](https://docs.karakeep.app/next/troubleshooting/#upgrading-meilisearch---migrating-the-meilisearch-db-version) 1. Noticed missing search results for newly added bookmarks. 2. Checked Meilisearch logs and found: ``` ERROR file_store: Can't access update file cdcea004-1007-41b2-b670-303323994fcf: No such file or directory (os error 2) ERROR index_scheduler: No such file or directory (os error 2) ``` 3. Stopped and removed the Meilisearch container. 4. Deleted the old data volume. 5. Recreated the container with a fresh volume. 6. Triggered a full reindex via the admin interface (successfully). 7. Performed a search → received “Something went wrong” message. 8. Meilisearch logs show: ``` WARN HTTP request{method=POST host="meilisearch:7700" route=/indexes/bookmarks/search query_parameters= user_agent=node status_code=400 error=Index `bookmarks`: Attribute `userId` is not filterable. This index does not have configured filterable attributes. ``` ### Expected Behaviour Search results should work after reindexing, especially for filters used by the UI like `userId`. ### Screenshots or Additional Context * I am the only user in the system. * I’m using [Pocket ID](https://github.com/pocket-id/pocket-id) as the OIDC provider. * Content of `.env`: ``` DATA_DIR=/data MEILI_ADDR: http://meilisearch:7700 MEILI_MASTER_KEY=[redacted] NEXTAUTH_URL=http://localhost:3000 NEXTAUTH_SECRET=[redacted] BROWSER_WEB_URL: http://chrome:9222 OPENAI_API_KEY: [redacted] NEXTAUTH_URL: "https://karakeep.[redacted]" DISABLE_SIGNUPS: "false" DISABLE_PASSWORD_AUTH: "true" OAUTH_ALLOW_DANGEROUS_EMAIL_ACCOUNT_LINKING: "true" OAUTH_PROVIDER_NAME: "Pocket ID" OAUTH_SCOPE: "openid email profile groups" OAUTH_CLIENT_ID: [redacted] OAUTH_CLIENT_SECRET: [redacted] OAUTH_WELLKNOWN_URL: https://auth.[redacted]/.well-known/openid-configuration INFERENCE_LANG: english OCR_LANGS: "deu,eng" TZ: "Europe/Berlin" ``` ### Device Details Google Chrome 136.0.7103.114 on macOS 15.5 ### Exact Karakeep Version v0.24.1 ### Have you checked the troubleshooting guide? - [x] I have checked the troubleshooting guide and I haven't found a solution to my problem

kerem

2026-03-02 11:53:44 +03:00

closed this issue
added the
bug

status/untriaged
labels

kerem commented

2026-03-02 11:53:45 +03:00

Author

Owner

@jk commented on GitHub (May 21, 2025):

I identified the issue and resolved it using the following command:

docker compose exec meilisearch ash
curl -X PATCH 'http://localhost:7700/indexes/bookmarks/settings' \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $MEILY_MASTER_KEY' \
 -d '{"filterableAttributes": ["id", "userId"], "sortableAttributes": ["createdAt"]}'

It appears that when initializing a new Meilisearch instance and performing a reindex, the index isn’t properly set up. Specifically, the filterableAttributes and sortableAttributes are not configured by default.

Additionally, I’ve noticed that during reindexing, the createdAt field is assigned the timestamp corresponding to the time of reindexing, rather than preserving the original metadata from Karakeep. As a result, sorting search results by “newest” or “oldest” yields incorrect orderings that don’t align with the dates displayed on individual items.

@jk commented on GitHub (May 21, 2025): I identified the issue and resolved it using the following command: ``` docker compose exec meilisearch ash curl -X PATCH 'http://localhost:7700/indexes/bookmarks/settings' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer $MEILY_MASTER_KEY' \ -d '{"filterableAttributes": ["id", "userId"], "sortableAttributes": ["createdAt"]}' ``` It appears that when initializing a new Meilisearch instance and performing a reindex, the index isn’t properly set up. Specifically, the `filterableAttributes` and `sortableAttributes` are not configured by default. Additionally, I’ve noticed that during reindexing, the `createdAt` field is assigned the timestamp corresponding to the time of reindexing, rather than preserving the original metadata from Karakeep. As a result, sorting search results by “newest” or “oldest” yields incorrect orderings that don’t align with the dates displayed on individual items.

kerem commented

2026-03-02 11:53:45 +03:00

Author

Owner

@MohamedBassem commented on GitHub (May 24, 2025):

@jk that's interesting. Karakeep is supposed to automatically do the attribute fixing on client creation here: github.com/karakeep-app/karakeep@5f3fe5d1a1/packages/shared/search.ts (L69)

So a bit surprised it didn't do it automatically. Unless you dropped the meillisearch index while the containers are still running.

As for the createdAt we do actually use the bookmark's createdAt (github.com/karakeep-app/karakeep@5f3fe5d1a1/apps/workers/workers/searchWorker.ts (L104)). What you're hitting is probably (https://github.com/karakeep-app/karakeep/issues/1335) which is something we fixed in the nightly build and is coming in the next release.

@MohamedBassem commented on GitHub (May 24, 2025): @jk that's interesting. Karakeep is supposed to automatically do the attribute fixing on client creation here: https://github.com/karakeep-app/karakeep/blob/5f3fe5d1a1ad0abd2890283cbff45086cbfa442e/packages/shared/search.ts#L69 So a bit surprised it didn't do it automatically. Unless you dropped the meillisearch index while the containers are still running. As for the `createdAt` we do actually use the bookmark's `createdAt` (https://github.com/karakeep-app/karakeep/blob/5f3fe5d1a1ad0abd2890283cbff45086cbfa442e/apps/workers/workers/searchWorker.ts#L104). What you're hitting is probably (https://github.com/karakeep-app/karakeep/issues/1335) which is something we fixed in the nightly build and is coming in the next release.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/karakeep#916

No description provided.

Rows
Columns