Trails don't appear in /trails and Attribute elevation_loss is not filterable

[mmanjos]

I have a strange issue I've been trying to fix ever since upgrading to 0.12.0

The list at /trails used to show all of my saved trails, but now none appear. They still appear to be in the database, though, because they can be accessed via direct link. Some of them also appear on the homepage.

I see the following in the logs for wanderer_web, which might be related:

MeiliSearchApiError: Attribute `elevation_loss` is not filterable. Available filterable attributes are: `shares _geo public distance elevation_gain date difficulty author completed category`.
43:57 distance >= 0 AND elevation_gain >= 0 AND elevation_loss >= 0 AND difficulty IN [easy,moderate,difficult] AND author = l6xy0e07iokojiy AND ((public = false OR author = l6xy0e07iokojiy) AND NOT shares = l6xy0e07iokojiy)
    at /app/node_modules/meilisearch/dist/bundles/meilisearch.cjs.js:378:19
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/meilisearch/dist/bundles/meilisearch.cjs.js:298:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'invalid_search_filter',
  type: 'invalid_request',
  link: 'https://docs.meilisearch.com/errors#invalid_search_filter',
  httpStatus: 400

I also get a lot of these messages:

[svelte-i18n] Message "trail" has syntax error: Incorrect locale information provided

It might? be possible that one of my trails has some bad data? I get this message in the logs when I try to load /map

MeiliSearchApiError: Bad longitude `-220.74320793206138`. Longitude must be contained between -180 and 180 degrees. 
78:97 _geoBoundingBox([85.05112899999995, 50.12384793206118], [-85.05112899999985, -220.74320793206138])
    at /app/node_modules/meilisearch/dist/bundles/meilisearch.cjs.js:378:19
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/meilisearch/dist/bundles/meilisearch.cjs.js:298:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'invalid_search_filter',
  type: 'invalid_request',
  link: 'https://docs.meilisearch.com/errors#invalid_search_filter',
  httpStatus: 400
}

[mmanjos]

I did remove my data.ms directory before starting 0.12.0 - here's the message from the compose startup:

wanderer-search  | ls: /meili_data/data.ms/indexes: No such file or directory
wanderer-search  | [2024-12-07T19:57:41Z INFO  meilisearch] Importing a dump of meilisearch `V6` from the 2024-06-15 21:42:11.500362 +00:00:00

[mmanjos]

Just to see what would happen, I tried restoring an old backup and stepping through every release from v0.8.2 up to latest, performing every upgrade along the way (I might have missed some earlier, so I wanted to test every release)

It looks like this issue might have started happening on my dataset as of v0.10.1

[mmanjos]

yeah, it seems to start as of v0.10.1 and affects every release up to and including v0.12.0:

wanderer-search  | [2024-12-07T20:18:40Z INFO  actix_web::middleware::logger] 172.18.0.4 "POST /indexes/trails/search HTTP/1.1" 400 498 "-" "node" 0.003917
wanderer-web     | MeiliSearchApiError: Attribute `elevation_loss` is not filterable. Available filterable attributes are: `author elevation_gain public category _geo shares completed date distance difficulty`.
wanderer-web     | 43:57 distance >= 0 AND elevation_gain >= 0 AND elevation_loss >= 0 AND difficulty IN [easy,moderate,difficult] AND ((public = true OR author = l6xy0e07iokojiy) OR shares = l6xy0e07iokojiy)
wanderer-web     |     at /app/node_modules/meilisearch/dist/bundles/meilisearch.cjs.js:378:19
wanderer-web     |     at Generator.next (<anonymous>)
wanderer-web     |     at fulfilled (/app/node_modules/meilisearch/dist/bundles/meilisearch.cjs.js:298:58)
wanderer-web     |     at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
wanderer-web     |   code: 'invalid_search_filter',
wanderer-web     |   type: 'invalid_request',
wanderer-web     |   link: 'https://docs.meilisearch.com/errors#invalid_search_filter',
wanderer-web     |   httpStatus: 400
wanderer-web     | }
wanderer-web     | ClientResponseError 0: Something went wrong while processing your request.
wanderer-web     |     at trails_search_filter (file:///app/build/server/chunks/trail_store-Ik1VwJaG.js:305:11)
wanderer-web     |     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
wanderer-web     |     at async load (file:///app/build/server/chunks/17-8AaLDQtW.js:41:20)
wanderer-web     |     at async load_server_data (file:///app/build/server/index.js:1772:18)
wanderer-web     |     at async Promise.all (index 1)
wanderer-web     |     at async render_data (file:///app/build/server/index.js:3035:19)
wanderer-web     |     at async resolve2 (file:///app/build/server/index.js:3994:22)
wanderer-web     |     at async auth (file:///app/build/server/chunks/hooks.server-248u8dmy.js:118:20)
wanderer-web     |     at async respond (file:///app/build/server/index.js:3898:22)
wanderer-web     |     at async Array.ssr (file:///app/build/handler.js:1243:3) {
wanderer-web     |   url: '',
wanderer-web     |   status: 0,
wanderer-web     |   response: {},
wanderer-web     |   isAbort: false,
wanderer-web     |   originalError: {
wanderer-web     |     name: 'MeiliSearchApiError',
wanderer-web     |     code: 'invalid_search_filter',
wanderer-web     |     type: 'invalid_request',
wanderer-web     |     link: 'https://docs.meilisearch.com/errors#invalid_search_filter',
wanderer-web     |     httpStatus: 400
wanderer-web     |   }
wanderer-web     | }
wanderer-search  | [2024-12-07T20:18:43Z INFO  actix_web::middleware::logger] 172.18.0.3 "GET /keys HTTP/1.1" 200 785 "-" "Meilisearch Go (v0.26.2)" 0.001835
wanderer-search  | [2024-12-07T20:18:43Z INFO  actix_web::middleware::logger] 172.18.0.3 "GET /keys HTTP/1.1" 200 785 "-" "Meilisearch Go (v0.26.2)" 0.000195
wanderer-search  | [2024-12-07T20:18:43Z INFO  actix_web::middleware::logger] 172.18.0.3 "GET /keys HTTP/1.1" 200 785 "-" "Meilisearch Go (v0.26.2)" 0.000250
wanderer-web     | [svelte-i18n] Message "trail" has syntax error: Incorrect locale information provided

[mmanjos]

ah I just saw this in the release notes for v0.10.1 (apologies; I skipped over a few releases so I've only been looking at v0.12.0 up until now):

Please note that trails created before this version will have a default elevation loss of 0. Edit & save to update.

Is there a way to do that for every trail? I have about 20 saved and I don't know how to access them all without the /trails page working to load them

[Flomp]

Hi,

It seems like one or more database migrations were not executed correctly.
This is the migration that should have made elevation_loss filterable:
https://github.com/Flomp/wanderer/blob/main/db/migrations/1731158298_update_sortable_filterable_attributes.go

But in your case, it did not work properly and as a result, you see the MeiliSearchApiError. I see two ways to fix the issue:

1. You can try and add the filterable attribute to your meilisearch instance manually:
   https://www.meilisearch.com/docs/learn/filtering_and_sorting/filter_search_results#configure-index-settings
2. You reapply the migrations by running ./pocketbase migrate down 22 && ./pocketbase migrate up from inside the PocketBase docker container. The 22 denotes the number of migrations to go down. Ensure that the aforementioned migration is on the list that PocketBase displays when asking you to confirm.

In both cases please back up your data before you attempt anything.

[mmanjos]

Thanks! It looks like that might have fixed it - at least, after re-applying those migrations, I'm able to see the trails again on v0.12.0 but only if I select the Hiking category first from the Trails page (it is unfilled by default and no trails are present until I select something)

Is this expected behavior for the trails page now, or is there another setting I need to apply? Changing the default category in my profile to something else, then changing it back to Hiking didn't help.

[mmanjos]

Actually, it looks like I'm able to get trails to appear again by selecting and then unselecting a difficulty - I'll keep trying to see what else helps

[mmanjos]

Here's an example of the behavior I'm seeing:

2024-12-14.13-14-17.mp4

[mmanjos]

ah, that might just be the way it's supposed to work - the demo page behaves the same. Is there any way to have the default filter just be all categories, all difficulty?