I think I'm seeing this on desktop as well. I thought it was from duplicate device names when investigating issue 682565, but now I'm starting to think that more recent builds just fail to correctly commit sessions data.

You can watch on chrome://sync-internals/ how the commit responses for the sessions commits come back with very small version numbers. That doesn't seem correct.

Also, if this made it into M57, we're going to need to merge back a fix.

I think M-57 has the issue, at least on iOS.

Whoops, meant to switch owner to gangwu@, who is sync's bug fixer this week. Upping priority. Adding all platforms until we find that it's not the case.

it seems on new client(M58), session commit version is quiet small, like 18, 23. but on old client(M56), the session commit version is big, like 1486144364972935, which is timestamp.
I think this is why server do not deliver new session updates from new client to other clients.
investigating why session version was changed.

Doesn't seem to repro for me on 57.0.2925.0

58.0.2992.0 seems to be healthy, 58.0.2993.0 seems to be broken.

https://chromium.googlesource.com/chromium/src/+log/58.0.2992.0..58.0.2993.0?pretty=fuller&n=10000

Cross that with https://chromium.googlesource.com/chromium/src/+log/da35973f48bcb04f071bd6038ffe4ebaa4299c8c/components/sync and we get two CLs that touch the sync component, 

https://chromium.googlesource.com/chromium/src/+/3c942aae9aaa0a5a04314090526d8f24560d65a6
https://chromium.googlesource.com/chromium/src/+/1a2a80c1d77869bdd124a06b64a26b287e14f048

The former is only a unit test, the latter is big, so maybe.

I'm starting to think watching the version on the tab is a red herring. The problem might be in the window entry. It goes out with "version":"0" and comes back with "version":"1", which healthy clients don't do. We might be hosed at that point.

Looking at the commit requests, I see that the tabs_datatype_enabled field set to false. If I modify the line https://cs.chromium.org/chromium/src/components/sync/engine_impl/commit_util.cc?q=tabs_datatype_enabled&sq=package:chromium&dr=C&l=73 to set the field to true at all times, tip of tree builds suddenly work.

ModelTypeRegistry used to have routing info for all types including PROXY_TABS. This caused tabs_datatype_enabled to be set to true. After my change (http://crrev.com/2649023006) only control types and types with data type controllers are considered enabled which doesn't include PROXY_TABS and causes tabs_datatype_enabled to be set to false.

Is someone working on this?  I can confirm that all open tab syncing has now been totally 100% broken in this browser for several versions (since build 58.0.2993.0).

I'm on the DEV x64 branch running 58.0.3000.4 dev (64-bit) and it's broken.  Has a fix hit the Canary branch yet?  Should I be switching to Canary it sure seems like major breaks in the basic browser functionality are taking a LONG time to get fixed.  Other browsers would NEVER sit for the weeks or months with a basic function like it's cloud sync that's so widely advertised being 100% non-functional.  If it were other browsers, this kind of break wouldn't last a DAY before an emergency patch would be issued to fix it.

Some of us rely on Chrome's syncing tabs across devices to actually work during the day, so a fix would be greatly appreciated!

I wrote a CL to fix this issue. I'll send it for review today.

Awesome, thanks!  How long is that process typically then for a fix to let's say hit Canary vs the DEV branch?

Canary (on desktop) should be rebuilt every day. I'm not sure about Dev, I thought it was rebuilt once a week. Looking at https://omahaproxy.appspot.com/ it looks like the last two Dev releases were 1/31 and 2/3. Which is faster than once a week.

If you need this fixed now, you could always switch to Beta or Stable temporarily.

Thanks I'm already on DEV might switch to Canary in the interim for next couple weeks until this <hopefully> hits DEV which is my usual branch since I'm DEV Chrome ext and web apps etc. usually is plenty stable branch other than the ongoing stupid "unpacked extensions" warning balloon that I've had an issue open on for literally YEARS now praying for someone to roll in a fix to allow disabling it.:)

I'll watch Canary sounds like this fix would be rolled in to the next nightly thanks for getting on it so quickly!

Changing from M-57 to M-58. I was not able to reproduce on M-57 desktop, and we're currently blocking beta promotion.

Lets verify if iOS somehow picked up this bug for M57, see comment #4. It's possible the first time this change landed, before it was initially reverted, was on M57 and that's what #4 was testing. Pavel, as you fix this, can you verify the latest M57 iOS build doesn't have this problem? If it does, we'll need to merge a fix. Otherwise we should be good.

Okay, jnaveen@ helped out and tested iOS 57.0.2987.25 beta and it does not present this problem. Could only repro on M58 clients (both desktop and iOS). So I think we're safe here.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5402cfa4cf2e6841bf3269bdfb8c3ee2bb3788cc

commit 5402cfa4cf2e6841bf3269bdfb8c3ee2bb3788cc
Author: pavely <pavely@chromium.org>
Date: Wed Feb 08 02:48:57 2017

[Sync] Register PROXY_TABS with ModelTypeRegistry to include it in enabled types

The issue is that PROXY_TABS type doesn't represent a type that gets synced
with the server, no entries are committed by the client or downloaded from the
server. Because of this PROXY_TABS doesn't need update handler in
ModelTypeRegistry. Unfortunately value of tabs_datatype_enabled is decided
based on the presence of PROXY_TABS in the set of enabled types.

The change I made is to register the type anyway thus including it in the set
of enabled directory types. It is not the ideal solution, but it is the
smallest, least invasive one. It limits ugliness to ProxyDataTypeController.

BUG= 688045 
R=skym@chromium.org

Review-Url: https://codereview.chromium.org/2684533003
Cr-Commit-Position: refs/heads/master@{#448873}

[modify] https://crrev.com/5402cfa4cf2e6841bf3269bdfb8c3ee2bb3788cc/components/sync/driver/proxy_data_type_controller.cc

I confirm that the latest build of M-57 works on iOS (syncs tabs correctly).
I will wait for the next canary to test on M-58

Thanks

Is this fixed at this point? Should we close it out?