Chunk size of 256 keys might be too large

[ivanik7]

I noticed that in the Find My app on a macOS VM, the tracker updates its location more frequently, then it does in Home Assistant. After experimenting with the code, I found the following:

In findmy/reports/reports.py::fetch_reports the large array of keys is spit into chunks of 256 entries. However, this doesn't work for me. If the chunk size greater than 64 elements, apple returns only some part of data, and the last location reports are missing.

How did you determine that 256 is a right size of chunks? Maybe there is a account limit?

Maybe a good idea would be to implement a function that searches only for the last known location. It could iterate over the rolling keys in reverse, from end to start, and stop as soon as the first batch returns results

[georgehosono]

I've been testing something similar, and I've found that each request to the server returns at most 20 reports. This means that if you request reports for 256 keys, you will not get reports for all of them. I found that requesting a single key at a time led to me receiving far more reports overall. It's possible that this behavior has changed recently?

I'm not sure where the number 256 comes from. The only citation I found for it is this issue here. #99 (comment)

[malmeloo]

I don't quite remember where I got the 256 limit from... when i started working on this library it felt like something that was generally known among people experimenting with the API, but I can't find a source for it anymore. That said, I did experiment with it myself back in the day and 256 keys worked perfectly for me, so I never bothered to change it.

I'm getting a few other signs as well saying that Apple changed something server-side that may have broken things. Also see this issue: biemster/FindMy#82 (although I wouldn't recommend the 'solutions' posted in that thread if you value your account).

[georgehosono]

Thanks for the reference. I'm using a spare account that I spun up for requesting reports, so I don't mind too much if I it gets blocked. Looking into the start and end dates sounds like a good clue.

[maalouf]

i am new to FindMy (so i cant say if worked before). i keep receiving a single result (one key) when i send multiple (even 2).
input an array of KeyPair, output one result. am i doing something wrong or it is a new limitation?

[malmeloo]

i am new to FindMy (so i cant say if worked before). i keep receiving a single result (one key) when i send multiple (even 2).
input an array of KeyPair, output one result. am i doing something wrong or it is a new limitation?

How many reports are you seeing for that one key that is returned? If it's somewhere around 20 then it's likely to be the same issue. It's difficult to use that API incorrectly, so either way I highly doubt you're holding it wrong 🙂

[maalouf]

Hello, thank you for the quick reply.
Indeed, I get around 18 records for a single key (the last one). I tried reducing the start and end dates — the result is fewer records, but still only for a single key (1 key = 1 device).
So for now, I'm using 3 parallel requests with a 2-second delay between calls for 36 keys, repeated hour, hoping not to get blocked.
I was planning for large-scale use, but this seems to make it unviable. I wonder how some Chinese companies manage it — they have millions of tags deployed commercially.
I'm not skilled enough to dig deeper, but please let me know if there's any way I can help. I'll be watching to see how this evolves.