Compatibility boundary: index rebuilds during FaunaDB schema field renames

We are evaluating a zero-downtime schema migration for a small FaunaDB application that depends on an index covering a field we need to rename. FaunaDB’s schema API documents additive changes as safe to apply without downtime, and breaking changes such as field renames are expected to follow a two-phase rollout where old and new fields coexist temporarily. The compatibility boundary becomes uncertain when the renamed field participates in an index: it is unclear whether the documented backward-compatibility guarantees for drivers and the HTTP API extend to index-backed queries while FaunaDB rebuilds the index internally, and current behavior should be verified against the active FaunaDB version.

Because the application cannot tolerate prolonged latency spikes, we need to identify which observable state changes confirm that a rebuilt index is fully active before the legacy field is removed.

Does FaunaDB guarantee index availability while rebuilding an index after an indexed field is renamed, or should we expect temporary query degradation? Is the two-phase field migration pattern sufficient to avoid downtime in this scenario? Which schema or transaction-log signals reliably confirm that an index rebuild has completed?