I have just reproduced this locally once on Linux, so it's not a Mac-specific issue. But only after reapplying https://chromium-review.googlesource.com/c/chromium/src/+/784790

I reproduced the DCHECK failure exactly once, afterwards the test passes, so there's flakiness.

Looks like the test is already mildly flaky on various platforms, occasionally crashing due to DCHECK: https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=sync_integration_tests&tests=TwoClientPasswordsSyncTest.SetPassphraseAndThenSetupSync

E.g. https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.chromiumos%2Flinux-chromeos-dbg%2F2989%2F%2B%2Frecipes%2Fsteps%2Fsync_integration_tests%2F0%2Fstdout

skym@: Any chance you or somebody else could take a quick look to see if my point is totally off and it's instead a bug in the test setup?

So the question, rephrased from #1, is: what prevents ModelTypeRegistry::OnPassphraseAccepted() from being called *before* the initial sync is finished?

Meanwhile, I'll try to make it reproducible by introducing some fake delays.

Huh, this is the USS worker that's blowing up, +pavely@

Regardless of what this test case is doing, it doesn't seem like the production code is correctly handling this... I think the worker could simply just not call ApplyUpdates() if model_type_state_.initial_sync_done() is false, and things would work. Eventually the PassiveApplyUpdates() will come through and get the cyrpto information to the proc.

I cannot think of any scenario this wouldn't work, where we'd prefer to skip the EncryptionAcceptedApplyUpdates() call from model_type_registry.cc. What do you think Pavel? By the point we know on the sync thread that we're going to shutdown, we should have disconnected the model's connection anyways... I think

Ugh, I hate it when it's my fault, I added this bug back in https://chromiumcodereview.appspot.com/2401083003

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

commit ad730d93fc6824eb684f453d59dcae99b5d3b486
Author: Sky Malice <skym@chromium.org>
Date: Tue Dec 05 22:10:37 2017

[Sync] Fix missing wait for initial sync to send crypto to proc

This avoid hitting a DCHECK that was introduced in
https://chromiumcodereview.appspot.com/2401083003 where we tried clean
up notifications to the model thread about encryption information.
By re-using the existing ApplyUpdates methods (and DCHECKs) we now
realize that we sometimes call ApplyUpdates before the initial sync is
completed. This is probably wrong and definitely, since the initial
sync will call ApplyUpdates and pass encryption information. Sending it
before that will just be confusing for the proc.

Bug:  789950 
Change-Id: Ifc2b01efbc71145574f9106c67ce9aebfc8f6b99
Reviewed-on: https://chromium-review.googlesource.com/807664
Reviewed-by: Pavel Yatsuk <pavely@chromium.org>
Reviewed-by: Mikel Astiz <mastiz@chromium.org>
Commit-Queue: Sky Malice <skym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521852}
[modify] https://crrev.com/ad730d93fc6824eb684f453d59dcae99b5d3b486/components/sync/engine_impl/model_type_registry.cc
[modify] https://crrev.com/ad730d93fc6824eb684f453d59dcae99b5d3b486/components/sync/engine_impl/model_type_worker.cc
[modify] https://crrev.com/ad730d93fc6824eb684f453d59dcae99b5d3b486/components/sync/engine_impl/model_type_worker.h
[modify] https://crrev.com/ad730d93fc6824eb684f453d59dcae99b5d3b486/components/sync/engine_impl/model_type_worker_unittest.cc