fix(destination): recreate an index with the source's own prefix lengths

[abnegate]

The defect

validateFieldsForIndexes() derives every index length from the destination column — null, or MAX_ARRAY_INDEX_LENGTH for an array column. The source's recorded prefix lengths are parsed into the Index resource and then never used: the class had no getLengths() at all.

An index often only fits under an adapter's byte limit because of that prefix. Two large string columns capped at 100 and 20 bytes are a perfectly valid index on the source and a 767-byte violation on the destination — so restoring a healthy database fails to recreate its own indexes:

Invalid index: Index length is longer than the maximum: 767

Why this matters

Measured against Appwrite Cloud production across all six regions: 3 separate customers in 3 regions hit exactly this signature, the most recent four days ago. One of them issued nine in-place restore attempts in eighty minutes, every one failing, before working around it (DAT-2113).

The fix

Lengths come from the resource being recreated. A recorded 0 — how a source records "no prefix" for a position, e.g. a short column that needs none — stays no-prefix rather than becoming a zero-length one. Array columns keep their MAX_ARRAY_INDEX_LENGTH override, which is a destination-side constraint rather than a source fact.

Tests

AppwriteIndexLengthsTest drives the real Appwrite destination through Transfer:

• an index with source prefixes [100, 20] is recreated carrying them;
• the same index without source lengths still fails the adapter's byte limit — the control case, proving the test exercises a genuinely limit-bound index rather than one that would fit anyway;
• a recorded 0 stays no-prefix (asserted in the shape a live production row for this exact case carries, [100, 0], since the metadata collection types lengths as an integer array).

Verified red against main: 2 of the 3 fail without the change. Full unit suite green (67 tests), Pint and PHPStan clean.

One note for reviewers: the test transfers the schema and the index in two run() passes, because Transfer::GROUP_DATABASES_RESOURCES orders TYPE_INDEX before TYPE_COLUMN — the reverse of what a real source emits. A single pass would offer the index against a table with no columns yet and test the mock's ordering rather than production's.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

The PR now preserves source index prefix lengths during destination validation and compares those lengths when reconciling an existing index.

• Adds Index::getLengths() so destinations can consume recorded source prefixes.
• Uses positive source prefix lengths while retaining the destination-specific array-column override.
• Adds migration tests for explicit prefixes, absent prefixes, zero sentinels, and overwrite reconciliation.

Confidence Score: 4/5

The PR is not yet safe to merge because unchanged array-column indexes can still be deleted and recreated on every eligible overwrite migration.

Index creation replaces an absent source prefix with MAX_ARRAY_INDEX_LENGTH for array columns, while the new comparator continues comparing persisted lengths against the unnormalized source value; the same index therefore appears different on every later overwrite, and recreation failure after deletion leaves the destination without it.

Files Needing Attention: src/Migration/Destinations/Appwrite.php

Important Files Changed

Filename	Overview
src/Migration/Destinations/Appwrite.php	Applies source prefix lengths during index creation and compares them during overwrite reconciliation, but array-column normalization remains inconsistent between creation and comparison.
src/Migration/Resources/Database/Index.php	Exposes the existing lengths field through a typed getter for destination consumers.
tests/Migration/Unit/Destinations/AppwriteIndexLengthsTest.php	Covers source prefixes, missing and zero lengths, and ordinary length-only overwrite mismatches, but does not cover repeated reconciliation of array-column indexes.

_{Reviews (3): Last reviewed commit: "fix(destination): compare index prefix l..." | Re-trigger Greptile}

[abnegate]

Greptile's finding is correct and now fixed.

indexSpecMatches() omitted lengths, so an Overwrite migration onto an index whose only difference was its prefix treated it as already matching and skipped it — silently keeping the destination's lengths, which reintroduces exactly the defect this PR fixes, on the overwrite path instead of the create path.

The exclusion was reasonable when it was written, and its comment said so: lengths were derived per-column from the adapter and not carried on the resource, so comparing them compared nothing. That is no longer true — the source's own lengths drive them now — so the comment and the behaviour both change. Positions compare as integers so "no prefix" matches however it is spelled (the resource records 0; the metadata collection reads back 0 or null).

On the test: it asserts the decision — that a length-only difference is no longer reported as STATUS_SKIPPED — rather than the full drop-and-recreate. The in-memory adapter cannot drop an index the destination believes it holds, which is an adapter limit rather than the behaviour under test; asserting around it would have been asserting an artifact. Verified red against the unfixed comparison.

Full unit suite green (68 tests), Pint and PHPStan clean.

[abnegate]

@greptileai review