Repository navigation
Description
Describe the bug
Alan Zimmer's November 6, 2026 audit of com.azure:azure-cosmos:4.84.0-beta.1 reports that migration to handleLatestVersionChanges can repeatedly fail initialization after an interrupted legacy split. Legacy split handling creates child leases before deleting the parent; a crash or failed deletion can legitimately leave both. Migration matching counts both an exact child lease and its parent, misclassifies the state as an unsupported merge, and fails initialization. Restarting does not repair the durable lease state. Reported priority: P1.
Exception or Stack Trace
No stack trace supplied; the audit reports an unsupported-merge classification.
To Reproduce
Leave legacy parent partition 0 and child partition 1 leases present after interrupted split handling, then migrate to handleLatestVersionChanges. Verify that initialization succeeds and that each resulting range preserves the appropriate checkpoint. This is a proposed regression scenario, not a runtime reproduction from the audit.
Code Snippet
Not supplied. Reported location: EPK PartitionSynchronizerImpl.java:219-239 in the audited source.
Expected behavior
An exact partition-ID lease match takes precedence. Parent leases are consulted only when no exact match exists, allowing migration to recover from interrupted split state without losing checkpoints.
Screenshots
N/A.
Setup (please complete the following information):
- OS: Not reported.
- IDE: Not reported.
- Library/Libraries:
com.azure:azure-cosmos:4.84.0-beta.1. - Java version: Not reported.
- App Server/Environment: Change Feed Processor migration from legacy leases to
handleLatestVersionChanges. - Frameworks: Not reported.
Dependency mismatch: Not indicated; dependency tree/logs were not supplied.
Additional context
Proposed fix from the audit: prefer an exact partition-ID match; consult parent leases only when no exact match exists.
Regression coverage: migrate interrupted split state containing parent 0 and child 1 leases and verify the appropriate checkpoint is preserved for each resulting range.
Evidence: Alan source-traced this finding through callers and recovery paths; it was not runtime-reproduced. No live Cosmos calls or full SDK test suite were run, and no repository files were changed. This issue tracks validation and implementation of the proposed fix, not an already-applied fix.
Information Checklist
- Bug Description Added
- Repro Steps Added
- Setup information Added
Activity