I suggest creating unit tests that swap out the request service in order to simulate the server. This is very important as shipping a version where the requests are broken has the potential to DDoS the server which will cause problems that we can't really fix without waiting it out for clients to update, and there will always be a long tail of clients that don't get updated. Some cases we need to test:

• A fresh sync sends no if-none-match
• A fresh sync where the server has data will send no if-none-match, a follow up will correctly set if-none-match
• Writing a sync and then syncing will set the expected if-none-match
• The cases we've had problems with already:
  • Syncing different versions where no changes exist Last synced keybindings and globalState not updating version when syncing with no changes #89817
  • AbstractSynchronizer.getRemoteUserData is called without lastSyncData seemingly on every sync #89623
  • Verify correct number of requests are being made Settings data is requested twice in a row during a sync #89626, when the new API is adopted this should go into details like fetching all latest, then fetching each resource individually and verifying the requests are correct
  • Correct handling/backing off when errors occur Back off from successive requests when sync results in a 401 #88317, Handle errors from server #85211
  • Verify correct data is being sent First sync of extensions seems to save [], followed shortly after by the actual manifest #85052

Consider starting on the framework for this as a minimum in Feb, we need a comprehensive test suite by the time we're out of preview.