Right now there's significant logic in fake_server.cc to track the progress markers that are returned, primarily orchestrated through the UpdateSieve class https://cs.chromium.org/chromium/src/components/sync/test/fake_server/fake_server.cc?l=57

There is a significant oddity however. The progress marker for a data type is essentially the max of that data type's GU request progress marker and the largest version number that returned an entity in this GU request regardless of type.

This can cause odd problems when clients don't always ask for the same sets of data types. For example, imagine all progress markers are at 0, but there's a new bookmark in the fake server with version 1. Client A GUs with all types, and now will have all progress markers set to 1. However if Client B calls GU with just the bookmarks type, they will have just bookmark's progress marker set to version 1, everything else will remain at 0. And they can call subsequent GU calls with all types and this will not change, unless another item is committed to some data type.

This doesn't make any sense, and has caused a problem when switching to USS device info, TwoClientSearchEnginesSyncTest.DisableSync started to fail when DeviceInfoSyncBridge didn't commit itself during merge. Although clients typically perform GU calls with all types, this isn't true during initialization. This test case disables sync and re-enables it for client index 1. A GU for priority types goes out first, and it misses version 30 that was created for the added search engine entity. Instead priority prefs gets stuck on version 29 and AwaitQuiescence() is never satisfied.

Two options here, either all progress markers share a max version, or each data type operates independently. I think the latter is preferable, if clients try to ask for smaller sets of model types based on invalidation, it may cause tests to fail when they didn't update the progress markers for types that didn't even change.

The behavior is actually fairly disjoint from reality. Real progress markers are a function of the current time, and pretty much always change on GU. However, we do not want to copy that behavior, we want to be able to check for equality in our testing. Using the clock time would cause everything to fail.