Skip to content

Conversation

@DomGarguilo
Copy link
Member

Fixes #5951

When a scan contained multiple duplicate keys and the scan broke or cut before returning all of those duplicates, the remainder of those duplicate keys were dropped and not returned when the scan resumed. This happened because when the scan cut, we did not store the MemKey which contains an additional field, kvCount which when used, distinguishes otherwise duplicate keys. When we resumed the scan without these MemKey details, the scanned picked back up after the logical key we left off on, which incorrectly skips the remaining duplicate keys in the scan. We now store the full MemKey and when the scan resumes on the same key, skips only the one entry we already returned so the other duplicate keys are correctly returned now.

The new test case fails without the rest of the changes and passes with them.

@DomGarguilo DomGarguilo added this to the 2.1.5 milestone Oct 10, 2025
@DomGarguilo DomGarguilo self-assigned this Oct 10, 2025
@DomGarguilo DomGarguilo added blocker This issue blocks any release version labeled on it. bug This issue has been verified to be a bug. labels Oct 10, 2025
@DomGarguilo DomGarguilo linked an issue Oct 20, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

blocker This issue blocks any release version labeled on it. bug This issue has been verified to be a bug.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Scanning a table without the versioning iterator can drop keys

1 participant