searchContinueV2 seems to not work on the last batch it should find

---

tfrysinger wrote:
...

...
    boolean keepGoin = true;
    while (matches.size() > 0 && keepGoin) {
...

What I am seeing is:

...

6. Step 4 occurs and since result.getHasMore() returns true, the searchContinueV2() is called. However this time, while getHasMore() is set to FALSE within the returned result (which is correct), there is no entry in 'matches', i.e. it is empty. The third and final directory was not found! WHY NOT?

...

---

Hi tfrysinger,

Greg-DBhas explained what's the reason for 'there is no entry in', already. In addition, I would like to note the logical error in your code related to the loop. Why aren't you trying to fix it, instead of looking for alternatives? 🤔🤷

At any one moment the 'matches' could be empty, despite there are matching entries! In such a case what's going to happen? -> You will never get in the loop and your code wouldn't do anything, if that happens at the beginning or will stop 'looping' at first such moment (in your case at the last entry).

Reasonable question here is why you are using as a loop criteria unreliable values combination? There is always chance for a 'pause', which can confuse your code. Dropbox API (including all SDKs - Java in your case) performs asynchronous calls and they can NOT be predicted or forced ('batch size' is nothing more than a wish declaration, which server tries to and in most cases follows, but without guaranties)! You should be able make your code expect everything possible. That's it - everything possible is what's everything not impossible (including 'unusual' empty transaction - it's actually usual). Wouldn't it be easier to reformat loop criteria to something like:

...
    while (matches.size() > 0 || result.getHasMore()) {
...

... or similar? 🙂 Just a little logic inversion, so loop can't break processing in such a way anymore. Have you tried something like? 😉

Hope this gives direction.