Thanks for keeping an eye on this, but it's a bit premature to file bugs until USS bookmarks is fully implemented (say, at least, until all integration tests have been enabled). In particular, local deletions are not yet implemented, so I'm wondering how you concluded there is a bug?

Furthermore, all USS types set up sufficient information for the server to know the datatype, as per https://cs.chromium.org/chromium/src/components/sync/engine_impl/non_blocking_type_commit_contribution.cc?l=226&rcl=ac6f267da8542f300d071cbaea765c94407d78f5

I'd be good to understand which fields you rely on server-side for tombstones: it feels like entity ID + datatype should suffice.

ascheglov@: friendly ping for questions from #1.

We rely on the current behavior, i.e. when the client sends full specifics for deleted bookmarks.  
So we're concerned whether the client would change its behavior when USS bookmarks will go into production.  

Thank you for providing more feedback. Adding the requester to the cc list.

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

ascheglov@yandex-team.ru@: bookmarks USS should be mature enough now for you to verify behavior. USS doesn't send populated entity specifics for deletions, so you should expect the same for bookmarks.

I'm wondering why you don't run into the same issue for other USS types.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.