fix: preserve unchanged collated indexes

[Bea (B-E-A-F)]

Expand declared collations through MongoDB before comparing index definitions, so equivalent collated indexes remain intact across syncs.

Fall back safely when expansion is unavailable or unrecognized.

Issue: HB-8770

[Copilot]

Pull request overview

Prevents repeated rebuilding of collated MongoDB indexes during synchronization.

Changes:

• Normalizes stored collations before comparison.
• Adds unit and ignored integration tests for collation synchronization.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/index.rs	Adds collation normalization and unit tests.
tests/indexes.rs	Adds MongoDB integration tests for collated indexes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Bea (B-E-A-F)]

(removed)

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

tests/indexes.rs:306

• Add the missing auxiliary verb so this documentation sentence is grammatical.

/// Documents the server behaviour the sync test depends on, and kept separate from it so a failure

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/index.rs:568

• explain requires authorization to execute its underlying find. This adds a new read privilege requirement to sync_indexes, so least-privilege credentials that can list/create/drop indexes but cannot read documents will now fail with Unauthorized whenever a matching collated index exists. Please avoid a find-based normalization mechanism or explicitly provide a compatible fallback/contract for these callers.

            "explain": { "find": collection, "filter": {}, "collation": collation },

src/index.rs:577

• These .ok() calls collapse a malformed or changed explain response into the same None used for locale: "simple". For any non-simple declaration, a missing queryPlanner.collation therefore strips the requested collation; if the existing index is collation-less, it can then be incorrectly marked synchronized instead of returning an error. Only treat an absent collation as valid for the simple locale and fail closed otherwise.

    Ok(ret
        .get_document("queryPlanner")
        .ok()
        .and_then(|planner| planner.get_document("collation").ok().cloned()))

src/index.rs:409

• The stated version carve-out is not implemented here: the expansion keeps the current server's ICU version, while existing_index keeps the version recorded when that index was created, and doc_are_eq compares them exactly. After an ICU/server upgrade this can still drop an otherwise unchanged collated index solely because those server-owned versions differ. Remove version from both server-produced collations before comparing them.

                        let expanded = expanded_collation(
                            db,
                            CollConf::collection_name(),
                            &declared_collation,
                        )

[Benoît Cortier (CBenoit)]

Thank you. Indeed, we should compare the compact collation against the expanded one, otherwise we end up dropping and rebuilding the index at every restart. The explain call role is to expand the declaration the same way the server would, so we can do the right comparison. The idea looks sound to me!

I’m attaching a few findings below.

[Benoît Cortier (CBenoit)]

Another nitpick: In this repository we are following the conventional commit specification: https://www.conventionalcommits.org/en/v1.0.0/

Roughly, the shape of the final, squashed commit should be something like:

fix: stop rebuilding collated indexes on every sync_indexes call

<some details>

Issue: HB-8770

Where the ticket/issue key is attached as a footer instead, and the PR title should match the commit summary.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/index.rs:618

• A planner with no top-level collation is treated as None whenever winningPlan.shards cannot be read. That includes unrecognized replies such as {"queryPlanner": {}} and malformed sharded replies where shards is not an array. apply_expanded_collation then removes the declared collation, so an existing uncollated index can compare equal and synchronization can incorrectly leave it uncollated. Validate a recognizable standalone planner before returning None, and report every other shape as unrecognized.

        return Ok(Some(collation.clone()));
    }

    if planner.contains_key("winningPlan") || planner.contains_key("namespace") {

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/index.rs:606

• A successful reply containing any queryPlanner object is currently treated as a recognized “no collation” response whenever winningPlan.shards is absent. For example, an unfamiliar { queryPlanner: {} } shape becomes Expanded(None), causing the declared collation to be removed before comparison; if the stored index is uncollated, synchronization can then incorrectly leave it unchanged. Validate the standalone planner shape as shard_collation does so unfamiliar responses take the safe rebuild fallback.

    match sharded {
        Some(shards) => collation_agreed_across_shards(shards),
        // A standalone planner that reports no collation: the index is stored without one.
        None => Ok(None),

[Benoît Cortier (CBenoit)]

LGTM!