Initial sync caching can be awkward for stateless clients that want to get fresh information

This issue has been migrated from [#15500](https://github.com/matrix-org/synapse/issues/15500).

---

I recently ran into a small catch with Synapse's implementation of sync: it caches sync responses by some token along the lines of `(user_id, device_id, since_token)` (and a few other fields which are not relevant for this case really).

This was well-intentioned: it is basically needed to make initial syncs taking longer than 30 seconds to compute possible — the client keeps requesting an initial sync until the response is available without timing out.

However, this can be problematic for client developers who actually want the freshest state. For example, a stateless CLI tool may want to fetch the latest state events and apply some changes based on what it sees.
Currently it is difficult to do so because it is hard to request a fresh/uncached sync response from Synapse.
This can introduce subtle bugs into CLI tools where they may have been executed less than 2 minutes ago, since they won't see any changes made in the meantime (and in my case it led to a critically embarrassing bug which I'm glad I noticed; I also notice someone else ran into this today and it was confusing to them!).

The best approach I've found is to write some unpredictable account data (for me: I write a freshly generated UUID into `net.librepush.sync_buster`) and keep syncing until you get an echo for it — at that point you know you have a fresh sync response. (It may also be possible to use to-device events if you're not using the admin API to log in to the user in question.)
Just bear in mind that the more often you run this tool in a 2 minute window, the higher the number of stale syncs you will see in a chain until you get the sync-busting echo.