Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible batching bug depending on number of objects batched #1588

Open
cbaker6 opened this issue Jan 2, 2021 · 2 comments · May be fixed by #1589
Open

Possible batching bug depending on number of objects batched #1588

cbaker6 opened this issue Jan 2, 2021 · 2 comments · May be fixed by #1589
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@cbaker6
Copy link
Contributor

cbaker6 commented Jan 2, 2021

I suspect there's a bug in arrayBySplittingArray , particularly:

NSArray *subarray = [array subarrayWithRange:NSMakeRange(index, length)];

I think there are two issues, but this is only a suspicion as there are no test cases for arrayBySplittingArray. I don't recall, how range works for objective-c, but if it's similar to swift, I'm sure there's an issue. Basically, batches can be missed when the number of objects go over the default batch limit of 50. I suspect most people are batching with < 50 objects so the issue won't show up there.

  1. The endpoint of the subarray should grow dynamically while iterating through the while loop, it currently isn't doing this properly. Should be index+length.
  2. If range works the same way as Swift, then it should be < the endpoint of the array or else it can jump out-of-bounds.

If someone wants to take this on, replicating the test cases I wrote for ParseSwift should detect the problem .

The ParseSwift equivalent for arrayBySplittingArray is here which can be used to fix the bug: https://github.com/parse-community/Parse-Swift/blob/f1de7e4a95d937bcc008bc5ef040ebba3ced7adb/Sources/ParseSwift/API/BatchUtils.swift#L35-L49

@cbaker6 cbaker6 added type:bug Impaired feature or lacking behavior that is likely assumed Needs Investigation labels Jan 4, 2021
@shlusiak
Copy link

shlusiak commented Jan 6, 2021

The NSMakeRange method takes a location and a length (not an end point), so passing in index and length here seems correct. https://developer.apple.com/documentation/foundation/1417188-nsmakerange?language=objc

length is either the batch size of 50 or the number of remaining elements in the array, whichever is smaller. I cannot see any off-by one situations in that algorithm either, could be give me an example in numbers where there would be an out-off-bounds access to array?

You linked https://github.com/parse-community/Parse-SDK-Android/blob/a5cfa1f9c6654281c76367ad8b3252e2499bb821/parse/src/main/java/com/parse/Lists.java#L67 in the other PR, but I can't see any issue in Android's implementation either. Android's subList takes a start index (inclusive) and an end index (exclusive) so that also looks correct.

The test case you linked is giving me a 404 error.

@cbaker6
Copy link
Contributor Author

cbaker6 commented Jan 6, 2021

The branch I linked was recently merged and deleted, the location on the main branch is here: https://github.com/parse-community/Parse-Swift/blob/main/Tests/ParseSwiftTests/BatchUtilsTests.swift

The linked file with the swift version is here: https://github.com/parse-community/Parse-Swift/blob/f124d0a45c079dba0324b9603e9e106f51ecb24e/Sources/ParseSwift/API/BatchUtils.swift#L34-L50

If what you mentioned is how range works for objective-c, then there may not be any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Impaired feature or lacking behavior that is likely assumed
Projects
None yet
3 participants