Issue with reverse getRange / conflictRange full range ignoring limit field

Using FoundationDB
1

Hi !

I’m trying to list keys in a range, with a given limit and either using the original or reversed order.

Looking at the fdb traces, the original listing will mark for ReadConflict only the range that was consumed by the client (start → limit). But when I use the reverse getRange, the entire range is marked for ReadConflict (end → start), ignoring the limit indicator.

I’m creating a message here first to get a feedback on my testing approach, to be sure the problem is worth creating an issue on the github repository.

My source used for tests & with logs : FDB Reverse read conflicting ranges · GitHub (Testing using fdb & bindings in versions 7.1.21 & 6.3.23 / apiversion 710 & 630).

I’m creating keys [32, 33, 34, … 62, 63], then listing from [42 → 51), with a limit of 5. The normal order locks [42 → 46], but the reversed order will lock [42 → 51).

Thanks you for having a look :slight_smile:

1 Like
2

Welcome!

I actually already discovered this issue: Read conflict range for reverse range read with a limit is too strict · Issue #7317 · apple/foundationdb · GitHub. It should be fixed by Fix bug in reverse range reads causing larger than desired conflict ranges by sfc-gh-ajbeamon · Pull Request #7329 · apple/foundationdb · GitHub, but I don’t think that has made it into a release yet.

As a work around for now, you can perform the reverse read at snapshot isolation and manually add the desired read conflict range based on the result. This is unfortunately kind of error-prone, but it looks like you’re pretty well set up to test it out based on your linked test java program. We could probably get some traction behind cherry-picking this to release-7.1 if you’re willing to wait a bit.