Dropbox Longpoll Bugs
I fixed a subtle bug in my dropbox client’s longpoll implementation.
Recently I noticed that one of my tools (which reloads the current webpage when a file in the corpus changes, according to dropbox,) was reloading the page way more than I expected.
I figured either I had a bug in my code or the Dropbox API was much weirder than I thought. It turns out that it’s somewhere in the middle.
Here’s what the longpoll API says:
A longpoll endpoint to wait for changes on an account. In conjunction with
list_folder/continue, this call gives you a low-latency way to monitor an account for file changes. The connection will block until there are changes available or a timeout occurs. This endpoint is useful mostly for client-side apps. If you’re looking for server-side notifications, check out our webhooks documentation.
That sounds like it monitors the entire account! But I played with the code some and found that the related call to continue is limited as you might hope. In short: the longpoll responses are account-wide, but the contents of the related responses are limited to the directory you start with.
The change I made wasn’t too complicated but of course I made plenty of mistakes along the way.
I doubt that the frequency I was reloading stuff was causing problems for Dropbox, my laptop, or the Raspberry Pi running the server code, but who doesn’t like making code much more efficient?
(Affiliate links below.)
Recently Brendan
Gregg’s Systems Performance
At the end of 2019 I read
BPF
Performance Tools
If you're interested in being notified when new posts are published, you can subscribe here; you'll get an email once a week at the most.