I'm adding more detailed steps to reproduce the problem, this is easier when triggering sync error states.
Steps to reproduce the problem:
This will be reproducible without PRE_COMMIT_UPDATE_AVOIDANCE(experiments, sync node browser).
1. Change clock behind 5 months.
2. Run browser and login to sync.
3. Trigger network error for sync response(that will put synced types in back off state).
4. Open first tab and type elg.no, then type ulv.no(typed_url), do not close tab.
5. Open second tab and type sau.no, then close this tab.
6. Go back to previous tab and type different url, leave tab.
7. Close browser.
8. Set date ahead, 1 month ahead.
9. Run browser, wait for sync(after login we are still in back off state)
10. Disable previously triggered network sync error. 
11. Observe sync internals and wait.

Michał Zajączkowski's patched introduced in:
https://chromium-review.googlesource.com/c/chromium/src/+/1151322

I wonder if this explains crbug.com/850893

Thanks for filing the bug. mzajaczkowski@opera.com has started as linked above in comment 3.

I think we cannot blame the TypedURLSyncBridge for not having the data available (after expiry) and thus causing the infinite loop.

A more appropriate fix (from the point of view of the Chrome Sync team) is being discussed in bug crbug.com/871733, I'll mark this as blocked on the other bug. Please continue in the discussion there.

If you disagree about the dependency, we can also discuss it here.

sync-triage-ping, the other bug came to conclusion how to fix, but this one is still blocked

jkrcal@: can you please provided a quick status update?

Friendly ping for jkrcal@, thanks.

This should be fixed thanks to https://chromium-review.googlesource.com/1233676. If you ever encounter it again, please re-open!