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.
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 got its second edition released. He wrote about it here. I am hoping to get a copy myself soon. I loved the first edition and think the second will be even more useful.
At the end of 2019 I read BPF Performance Tools. It was one of my favorite tech books I read in the past five years. Not only did I learn how to (almost) trivially see deeply inside of how my computer is working, but I learned how that works via the excellent detail Gregg added in each chapter. Amazing stuff.Posted Sat, Jan 9, 2021
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.