filesListFolderLongpoll fires changes: without changes within the folder

It's at least possible that in this case my app could ignore/not store the returned cursor and just restart the longpoll but that seems hacky

Thanks for the report. For clarity though, can you also share the code and parameter values you're using, e.g., for filesListFolder, filesListFolderContinue, and filesListFolderLongpoll? That would help make sure we investigate the right scenario.

Also, when you say this "results in a false positive change-loop", do you mean you're getting stuck in a `changes:true` -> ` "entries": [], ...,"has_more": false` infinite loop, or does that happen just once per change?

Sure! Here's how I repro'd it on my side:

I called https://dropbox.github.io/dropbox-api-v2-explorer/#files_list_folder/get_latest_cursor

with path: "/Apps/Songbook.Studio/Library" (if you need ids from me instead let me know)

then I called https://dropbox.github.io/dropbox-api-v2-explorer/#files_list_folder/longpoll

with cursor: "AAHYcbsJjEIIcObeUpf7Uu9QgkTFe0-6zAH3f43ypSgDm035GKew13WormET99lOBzz9Z9HCKOEapDe_Gp4fCP0TqDKb_FF6yHe6RnACghIQJSa7XT4HrKj2wKFvAFsWOl89bqvtBD0VYZ4JPvGzpmuSJ_xyjFjJH9-SnkxRe7Q0148beWvf71Jk68ukBNnsawn7jutFHLzS82LzJhA4y4z2fNjMvTx9yB8c61gakAVkGhG7v73CsiFpNNHfcxzbqpE"

it sits and spins...

I went to the Dropbox web UI and dragged/dropped a test image file (foo.png) into the parent folder: "/Apps/Songbook.Studio"

the longpoll returns with `changes: true` at this point

I call https://dropbox.github.io/dropbox-api-v2-explorer/#files_list_folder/continue

with cursor: "AAHYcbsJjEIIcObeUpf7Uu9QgkTFe0-6zAH3f43ypSgDm035GKew13WormET99lOBzz9Z9HCKOEapDe_Gp4fCP0TqDKb_FF6yHe6RnACghIQJSa7XT4HrKj2wKFvAFsWOl89bqvtBD0VYZ4JPvGzpmuSJ_xyjFjJH9-SnkxRe7Q0148beWvf71Jk68ukBNnsawn7jutFHLzS82LzJhA4y4z2fNjMvTx9yB8c61gakAVkGhG7v73CsiFpNNHfcxzbqpE"

and the response is:

{ "entries": [], "cursor": "AAHp_o9htUtsuvBy6ZLjlTyxIetGJZKp64hcFe641rOod28dbdiXDDw18CXg4T1DtBXDPexxpdzO9K8x8s7iX6YDB6XLcyzAJCPwb5xQuXSyXEbnjOEptD1xNvCUAG0hxxnWN5TgPl3fd-urlcaMtmzvt-0rVRg-RmKxJsbgp_7cKMrccWDoodbQFmNe2DrvY0nSgedfTcMxzWktRANN0hP8zzsv9uXrR4vZgoNaYPEv7BKQLZgdgBCiZHJvV1__tQ4h0AOpFvFK67An_KMgMgJwDZMQ7DnckIBAfoboOrJm5g", "has_more": false }

What I mean by the loop in my situation is that everytime I get a new cursor I update a file "/Apps/Songbook.Studio/.preferences.json" as my "durable storage" for the user's last update. When I do that, it triggers the longpoll's to return with the cycle described, so I have a kind of infinite back and forth. 

Got it, thanks! That's helpful. We'll look into it.

In the meantime, what do you think about my idea of preserving the original cursor and just starting the poll again?

That seems like a reasonable way to workaround the issue. As long as you don't get and process any new entries and still reach `has_more:false`, it would be fine to fall back to original cursor to avoid making another change, which would trigger that loop again. If/when you do get actual changes returned, you can then process them and save the next cursor. (Saving that new cursor would trigger this issue again, but that would just be the one extra iteration of the loop.)