Mikel, maybe you can take a look, one you're back, since I think you're the last one, who worked with sessions.

Thanks for filing a bug!

Do you have multiple devices?

Is it possible that you opened 100+ tabs at some point?

Sync code tries to reuse session sync entities and has two mechanisms that trigger deletion:
1. If there are too many "unused" local tab entities (should be your case, if the 528 entities are truly from the device you're testing).
2. Garbage colletion of tabs from other devices (e.g. if you uninstall chrome in one of your devices).

Can you describe your usage pattern more in detail?

Hi,
I use 3 devices with sync for this account: 2 PC and 1 smartphone.
I not sync history, I use specific password for sync, I use Chrome without cache.


no tabs on smartphone, all are close + 2nd PC not running chrome now + 6 tabs on my PC.
Not possible I open 100+ tabs.

I see 607 session on chrome://sync-internals this day
and 3 tabs in history 'tabs other device' for my 2nd PC, 6 days ago

Sync-internals dump for sessions: https://drive.google.com/file/d/1RE1giNdjMnWmUMrhk5A8AqaC0B-SZqm9/view?usp=sharing

Thanks!

In chrome://sync-internals tab "Sync Node Browser" and type "Sessions", would you mind going through some samples and inspecting:
1. Modification times (MTIME).
2. NON_UNIQUE_NAME.

From NON_UNIQUE_NAME, you should be able to tell which device contributed to that entity.

I'd like to understand whether these are locally created entities, and how old they are.

more entry for each 3 devices, with 


  "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "SCLUXAH78 (tab node 13)",
...
 "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "SCLUXAH78 (tab node 19)",
...
"MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "SCLUXAH78 (tab node 469)",
...
"MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "DAVID-PC (tab node 10)",
...
 "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "DAVID-PC (tab node 152)",
...
 "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "DAVID-PC (tab node 407)",

 "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "GT-I9300 (header)",
..
 "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "GT-I9300 (tab node 13)",

 "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "GT-I9300 (tab node 46)",



One entry (I remove all ID,hash, I do not know if there is confidential information)

{
  "CLIENT_TAG_HASH": "",
  "CREATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
 
  "IS_FOLDER": false,
  "MODIFICATION_TIME": "jeudi 1 janvier 1970 à 01:00:00",
  "NON_UNIQUE_NAME": "DAVID-PC (tab node 250)",
  "PARENT_ID": "",
  "SERVER_DEFINED_UNIQUE_TAG": "",
  "SPECIFICS": {
    "session": {
      
      "tab": {
        "tab_id": "1059206552"
      },
      "tab_node_id": "250"
    }
  },
  "UNIQUE_POSITION": "INVALID[]",
  "metadata": {
    "acked_sequence_number": "7",
    
    "creation_time": "1534583483700",
    "is_deleted": false,
    "modification_time": "1534583922697",
    "sequence_number": "7",
    
    "server_version": "1534583933474928",
    
  },
  "modelType": "Sessions"
}

similar problem with my 2nd Google account (full sync enabled for this account), with currently 269 synced sessions that can not be emptied. Delete all history does not empty sessions.

I notice that history uses records in sessions. While the https://chrome.google.com/sync?hl=en only indicates 'Open tab' (not history).
The problem probably exists since Google has shared the history of each Chrome when previously the history was specific to each Chrome.
-Remove all history on 2 devices not reduce sessions entries
-disable history and tabs sync, remove sessions entries but locally only.. after enable history or tabs sync it restore all previous entries.

There's two issues discussed here: one is history deletions, and how that should impact synced tabs that have previously been closed.

The other issue is why those tabs are not garbage collected.

Taking a look at your timestamps, it looks fishy (all 1970, i.e. Unix epoch). Chances are that we have a bug there, let me take a closer look.

OK, the timestamp issue is, unfortunately, red-herring: we have a bug in the debug UI that always displays 1970 for USS types.

Can you instead get the timestamps from the "metadata" section, e.g. lowercase "creation_time", which is a numeric value?

DAVID-PC (tab node 0)
"creation_time": "1533274650482",
"modification_time": "1533365114811",

DAVID-PC (tab node 114)
 "creation_time": "1534016275679",
 "modification_time": "1534089539962",

DAVID-PC (tab node 1082)
"creation_time": "1489596907471",
"modification_time": "1529700015397",

DAVID-PC (tab node 258)
"creation_time": "1534670213100",
"modification_time": "1534705913737",

DAVID-PC (tab node 408
"creation_time": "1535971130002",
"modification_time": "1535998996269",

GT-I9300 (header)
"creation_time": "1517386066126",
"modification_time": "1535387435672",

GT-I9300 (tab node 13)
"creation_time": "1517947514514",
"modification_time": "1526707435365",

GT-I9300 (tab node 46)
"creation_time": "1527195287953",
"modification_time": "1527237986873",


For other PC record, it's clean now after previous action but always see 696 synchronized sessions

SCLUXAH78 (tab node 0)
"creation_time": "1533536034017",
"modification_time": "1536062690902",

SCLUXAH78 (tab node 6)
"creation_time": "1533542492411",
"modification_time": "1536063439366",

The only header node listed above is relatively fresh (for GT-I9300), and I assume that's the case for all your devices (i.e. you use them all).

This means GC of sessions won't kick in. This means each device is responsible for deleting their own entities, via SyncedSessionTracker::CleanupLocalTabs(). This starts to sound similar to  crbug.com/847325 .

Yes, I use all.
and yes sound similar with  Issue 847325 
Very long time I use "Continue where you left off"

Thanks for confirming. I'm bumping priority because this seems to be affecting many users.

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

commit c8e98722a8f88e4669cff3c406813fee6688407c
Author: Mikel Astiz <mastiz@chromium.org>
Date: Wed Sep 05 11:08:29 2018

Fix tab nodes not marked as free during restore

When the local session is restored from persistence, if there are orphan
tabs, they should be marked as free, to prevent newly created tabs from
creating new tab nodes, instead of recycling available ones.

The restore flow exercises SyncedSessionTracker::CleanupSession(), which
prior to this patch wasn't smart enough for the local session.

Bug:  875671 , 847325 
Change-Id: I91f9f13ad4aedbbd85bfcc73c606096781b80527
Reviewed-on: https://chromium-review.googlesource.com/1204134
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#588827}
[modify] https://crrev.com/c8e98722a8f88e4669cff3c406813fee6688407c/components/sync_sessions/session_sync_bridge_unittest.cc
[modify] https://crrev.com/c8e98722a8f88e4669cff3c406813fee6688407c/components/sync_sessions/synced_session_tracker.cc
[modify] https://crrev.com/c8e98722a8f88e4669cff3c406813fee6688407c/components/sync_sessions/synced_session_tracker.h
[modify] https://crrev.com/c8e98722a8f88e4669cff3c406813fee6688407c/components/sync_sessions/test_synced_window_delegates_getter.cc
[modify] https://crrev.com/c8e98722a8f88e4669cff3c406813fee6688407c/components/sync_sessions/test_synced_window_delegates_getter.h

Requesting merge for the fix above, although it doesn't fix all reported issues.

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 80000c1f89dc2b0b3a0997c1b5321a29402aa977
Author: Mikel Astiz <mastiz@chromium.org>
Date: Sat Sep 08 06:35:23 2018

Fix tab nodes not marked as free during restore

When the local session is restored from persistence, if there are orphan
tabs, they should be marked as free, to prevent newly created tabs from
creating new tab nodes, instead of recycling available ones.

The restore flow exercises SyncedSessionTracker::CleanupSession(), which
prior to this patch wasn't smart enough for the local session.

Bug:  875671 , 847325 
Change-Id: I91f9f13ad4aedbbd85bfcc73c606096781b80527
Reviewed-on: https://chromium-review.googlesource.com/1204134
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#588827}(cherry picked from commit c8e98722a8f88e4669cff3c406813fee6688407c)
Reviewed-on: https://chromium-review.googlesource.com/1215022
Reviewed-by: Mikel Astiz <mastiz@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#185}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/80000c1f89dc2b0b3a0997c1b5321a29402aa977/components/sync_sessions/session_sync_bridge_unittest.cc
[modify] https://crrev.com/80000c1f89dc2b0b3a0997c1b5321a29402aa977/components/sync_sessions/synced_session_tracker.cc
[modify] https://crrev.com/80000c1f89dc2b0b3a0997c1b5321a29402aa977/components/sync_sessions/synced_session_tracker.h
[modify] https://crrev.com/80000c1f89dc2b0b3a0997c1b5321a29402aa977/components/sync_sessions/test_synced_window_delegates_getter.cc
[modify] https://crrev.com/80000c1f89dc2b0b3a0997c1b5321a29402aa977/components/sync_sessions/test_synced_window_delegates_getter.h

sync-triage ping: mastiz@ any progress here? can this get closed?

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

commit a6f711fd64fb69209c46ca3eb00b227e2267c1c4
Author: Mikel Astiz <mastiz@chromium.org>
Date: Thu Sep 20 13:08:50 2018

Untrack sync entity metadata if data is gone

This is a mitigation to what are believed to be bugs in the bridges,
which may forget to appropriately report local deletions to the
processor, leading to orphan sync metadata.

We have recently instrumented a UMA metric
("Sync.ModelTypeOrphanMetadata") to assess the severity of the issue,
and the collected data suggests that the problem is not specific to a
single datatype. While we investigate each bridge individually, a
reasonable workaround is to let the processor remove the orphaned
metadata and untrack the entity.

Bugs in the bridges should still be surfaced by the aforementioned
UMA metric, although absolute numbers should tend to be smaller after
this patch, because issues will get fixed after emitting the metric
once.

Bug:  875671 ,871733
Change-Id: Ieb06692f46739d73ce6f04115c25e14198ade1dd
Reviewed-on: https://chromium-review.googlesource.com/1233676
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Jan Krcal <jkrcal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592775}
[modify] https://crrev.com/a6f711fd64fb69209c46ca3eb00b227e2267c1c4/components/sync/model_impl/client_tag_based_model_type_processor.cc
[modify] https://crrev.com/a6f711fd64fb69209c46ca3eb00b227e2267c1c4/components/sync/model_impl/client_tag_based_model_type_processor_unittest.cc

I'm marking this as fixed since we addressed two important issues that contributed to the described problem. Should be shipped with Chrome version 71.

Please add a comment here is file a new bug if the issue persists. Sorry for the inconveniences and thanks for reporting!