mirror of
https://github.com/qdrant/qdrant.git
synced 2026-07-23 11:11:00 -05:00
* test: add failing tests for non-idempotent resharding consensus ops Add unit tests proving that resharding operations (abort, commit_read, commit_write, finish) return `BadRequest` errors instead of `Ok` when re-applied or when local state diverges between peers. Since `apply_entries` silently swallows all non-`ServiceError` results (including `BadRequest`), these errors cause permanent resharding state divergence between peers while consensus term/commit remain identical. All 6 tests fail on dev, demonstrating the bug. Made-with: Cursor * fix: make resharding consensus operations idempotent (#8523) * fix: make resharding consensus operations idempotent When apply_entries processes a resharding operation that returns BadRequest (not ServiceError), the error is silently swallowed and the entry is marked as applied. If local state on a peer diverges (crash during partial apply, prior swallowed error), the same committed Raft entry produces different outcomes on different peers — permanent resharding state divergence despite identical consensus term/commit. Fix by making all resharding operations return Ok when the desired post-condition is already met: ShardHolder level: - check_abort_resharding: return Ok when no resharding active or different resharding active (already aborted) - commit_read_hashring: return Ok when no resharding or stage already past ReadHashRingCommitted - commit_write_hashring: return Ok when no resharding or stage already past WriteHashRingCommitted - check_finish_resharding: return Ok when no resharding (already finished) - check_start_resharding: warn instead of error when shard already exists for Up direction (leftover from crashed previous attempt) Collection level (defense in depth): - start_resharding: return Ok if same resharding already in progress - commit_read/write_hashring: return Ok if no resharding or past stage - finish_resharding: return Ok if no resharding active - abort_resharding: return Ok if no resharding active Made-with: Cursor * Fix formatting issue * Remove resharding idempotency note from logs * Don't hold shard holder lock * Committing read/write hash rings are idempotent now and are allowed --------- Co-authored-by: Cursor Agent <agent@cursor.com> Co-authored-by: timvisee <tim@visee.me> --------- Co-authored-by: Cursor Agent <agent@cursor.com> Co-authored-by: timvisee <tim@visee.me>