Enum StopSyncResponse seemed to make sense at the time it was introduced, motivated by sessions sync, but it has recently conflicted with new features and the code in ClientTagBasedModelTypeProcessor has gone out of hands.
It seems like the enum has reasonable alternatives these days: creating the leveldb itself is not expensive, even reading sync metadata, and from that point on it is simple to optimize the codepath for non-sync users, which was the main motivation for the optimization in place.
For sync users, it's questionable whether we want to defer work until sync engine itself starts.
Comment 1 by treib@chromium.org
, Aug 13