Fix conditional indexing with enqueue mode in ms_enqueue_index!

[whitemerry]

Pull Request

Related issue

Fixes #426

What does this PR do?

Fixes conditional indexing when using enqueue: true option. Previously, when a record no longer met the indexing condition (e.g., if: :published? returned false), the document would remain in the Meilisearch index instead of being removed.

Code reflects logic implemented in ms_index! method.

PR checklist

Please check if your PR fulfills the following requirements:

• Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
• Have you read the contributing guidelines?
• Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Summary by CodeRabbit

• Bug Fixes
  • Improved search index update logic to properly handle conditional indexing rules and background job enqueueing, ensuring items are indexed or removed from search based on configured settings.

[coderabbitai]

Walkthrough

The ms_enqueue_index! method now conditionally handles document indexing and removal based on indexability and enqueue configuration. Previously, non-indexable documents were ignored; now they are enqueued for removal or directly removed if conditions warrant it, mirroring the behavior of ms_index!.

Changes

Cohort / File(s)	Summary
Conditional indexing logic in ms_enqueue_index! lib/meilisearch-rails.rb	Reworked control flow to branch on indexability: if indexable, enqueue indexing (or directly index); if not indexable but conditional indexing enabled, enqueue removal (or directly remove). Replaces previous early-return behavior that skipped removal for non-indexable documents.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant ms_enqueue_index!
    participant Utilities
    participant Enqueue Handler
    participant Index
    participant ms_index!

    Caller->>ms_enqueue_index!: ms_enqueue_index!(synchronous)
    
    ms_enqueue_index!->>Utilities: indexable?(document, options)
    
    alt Document is indexable
        Utilities-->>ms_enqueue_index!: true
        alt Enqueue configured
            ms_enqueue_index!->>Enqueue Handler: call(self, remove=false)
            Enqueue Handler->>Index: background job → add_documents
        else No enqueue config
            ms_enqueue_index!->>ms_index!: ms_index!(synchronous)
            ms_index!->>Index: add_documents
        end
    else Document not indexable
        Utilities-->>ms_enqueue_index!: false
        ms_enqueue_index!->>Utilities: ms_conditional_index?(options)
        alt Conditional indexing enabled
            Utilities-->>ms_enqueue_index!: true
            alt Enqueue configured
                ms_enqueue_index!->>Enqueue Handler: call(self, remove=true)
                Enqueue Handler->>Index: background job → delete_document
            else No enqueue config
                ms_enqueue_index!->>ms_index!: ms_remove_from_index!(synchronous)
                ms_index!->>Index: delete_document
            end
        else Conditional indexing disabled
            Utilities-->>ms_enqueue_index!: false
            Note over ms_enqueue_index!: No action taken
        end
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Logic branches: Verify that both indexable and non-indexable paths correctly invoke enqueue or synchronous operations
• Conditional removal path: Ensure the new removal branch correctly handles ms_conditional_index? and that enqueue calls pass remove=true
• Consistency verification: Confirm that the behavior now mirrors ms_index! in both indexing and removal scenarios
• Edge cases: Check boundary conditions where enqueue is nil or indexing is disabled

Poem

🐰 A rabbit once watched documents drift into the void,
When conditions changed, yet the old code left them deployed.
Now indexing and removal dance in perfect sync,
Conditional logic branches without a blink,
Enqueued or direct, both paths now reply—
Consistency blooms where chaos used to fly! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main fix: conditional indexing now works correctly with enqueue mode in ms_enqueue_index!
Linked Issues check	✅ Passed	The PR changes align with issue #426 requirements: ms_enqueue_index! now enqueues removal jobs when documents become non-indexable, mirroring ms_index! behavior.
Out of Scope Changes check	✅ Passed	All changes are focused on fixing conditional indexing logic in ms_enqueue_index!, directly addressing the linked issue without unrelated modifications.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

lib/meilisearch-rails.rb (1)

956-974: LGTM! Successfully aligns with ms_index! behavior.

The implementation correctly addresses the issue where non-indexable documents weren't being removed from the index when using enqueue mode. The two-branch structure now mirrors the logic in ms_index! (lines 562-591):

• Indexable documents → enqueue indexing (or fallback to synchronous)
• Non-indexable with conditional indexing → enqueue removal (or fallback to synchronous)

The nested conditional blocks at lines 958-961 and 966-969 are nearly identical and could be refactored to reduce duplication:

 def ms_enqueue_index!(synchronous)
-  if Utilities.indexable?(self, meilisearch_options)
-    if meilisearch_options[:enqueue]
-      unless self.class.send(:ms_indexing_disabled?, meilisearch_options)
-        meilisearch_options[:enqueue].call(self, false)
-      end
-    else
-      ms_index!(synchronous)
-    end
-  elsif self.class.send(:ms_conditional_index?, meilisearch_options)
-    if meilisearch_options[:enqueue]
-      unless self.class.send(:ms_indexing_disabled?, meilisearch_options)
-        meilisearch_options[:enqueue].call(self, true)
-      end
-    else
-      ms_remove_from_index!(synchronous)
+  is_indexable = Utilities.indexable?(self, meilisearch_options)
+  should_process = is_indexable || self.class.send(:ms_conditional_index?, meilisearch_options)
+  
+  return unless should_process
+  
+  remove = !is_indexable
+  
+  if meilisearch_options[:enqueue]
+    unless self.class.send(:ms_indexing_disabled?, meilisearch_options)
+      meilisearch_options[:enqueue].call(self, remove)
     end
+  else
+    remove ? ms_remove_from_index!(synchronous) : ms_index!(synchronous)
   end
 end

This reduces cognitive complexity while preserving the same logic.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 16e4d4b and d08785c.

📒 Files selected for processing (1)

• lib/meilisearch-rails.rb (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

lib/meilisearch-rails.rb (1)

lib/meilisearch/rails/utilities.rb (1)

• indexable? (44-49)

[whitemerry]

I will add unit tests once the logic will be pre-approved - but looking at default mode and it's specs - that's valid approach.
Reproduction script from ticket #427 is green on this PR.

https://github.com/meilisearch/meilisearch-rails/blob/main/spec/integration/active_record/record_is_updated_spec.rb#L15

[whitemerry]

@coderabbitai generate docstrings

[coderabbitai]

✅ Actions performed

Initiated docstring generation; will generate only if new commits exist.

[coderabbitai]

Note

Docstrings generation - SUCCESS
Generated docstrings for this pull request at #428