Use of generic @configurations class ivar can collide with other gems (observed with algoliasearch-rails)

[kiyohara]

Description

meilisearch-rails caches per-model configurations using a very generic class instance variable name: @configurations (on the model class). This name is common enough that it can easily collide with other libraries that extend the same model class.

I observed a concrete collision when algoliasearch-rails is also included in the same model: both gems use @configurations on the model class, and whichever runs last overwrites the cache. As a result, meilisearch-rails can read a foreign configuration (Algolia settings) and send it to Meilisearch’s settings API, causing 400 errors.

Even if the “Algolia + Meilisearch in one model” use case is not common, the underlying problem is broader: @configurations is a high-risk ivar name for a public integration gem, because the collision pattern can happen with any other gem that uses the same ivar name on the same model class.

Expected behavior

• meilisearch-rails should not be affected by unrelated gems that extend the same model.
• Internal caches should be isolated (or namespaced) so that configuration/state cannot be overwritten externally.

Current behavior

When another gem uses @configurations on the same model class, meilisearch-rails may read the wrong cache and attempt to update Meilisearch settings with invalid keys, resulting in errors like:

• 400 Bad Request - Unknown field ranking
• warnings about keys such as indexLanguages, queryLanguages, attributesForFaceting, customRanking

Screenshots or logs

Example (Rails console):

MyBook.ms_set_settings
# => may succeed

MyBook.last.index!  # Algolia indexing path

MyBook.ms_set_settings
# WARN: Non-conforming attributes: searchableAttributes, attributesForFaceting, customRanking, queryLanguages, indexLanguages
# Meilisearch::ApiError: 400 Bad Request - Unknown field `ranking`

Also, MyBook.send(:ms_configurations).keys can include non-Meilisearch option hashes (e.g. :index_name, :replica, :primary_settings), indicating the Meilisearch configuration cache was overwritten.

Environment

Operating System: macOS (Rails in Docker)

Meilisearch version (./meilisearch --version): Meilisearch Cloud (Meilisearch version v1.42.1)

meilisearch-rails version (bundle info meilisearch-rails): 0.16.0

rails version (bundle info rails): 7.0.8.7

Reproduction script:

High-level reproduction (any Rails app where another gem sets @configurations on the same model class):

1. Include Meilisearch::Rails in a model and define a meilisearch block.
2. Load/use another library that caches something on the same model class using @configurations.
3. Call Model.ms_set_settings or record.ms_index!.

Observed reproduction with algoliasearch-rails:

MyBook.ms_set_settings
MyBook.last.index!       # algoliasearch-rails
MyBook.ms_set_settings   # may fail with Meilisearch::ApiError

Suggested fix

Avoid using a generic class ivar name like @configurations on the model class. Use a gem-specific name (e.g. @meilisearch_configurations) or isolate the cache in a dedicated structure to prevent collisions with other integrations that extend the same model.