Yeah, looks like we need to delay creating a StatusUploader until after we've been notified that the DeviceCloudPolicyClient is registered. Sergey, can you find someone on your team to take a look?

Looks like that bug arises if there are different opinions about if client is cloud-registered: it is so according to install attributes, but not to policy store.

That explains why I couldn't reproduce it on my testing device.

hansberry@, could you please provide more info about how did you run into this? Ex. was your device enrolled/just powerwashed/filled with a new chromeos build?

And, if you will run into this next time, could you please provide more lines of stacktrace? I wonder where TryToCreateClient was called.

I found an old bug on the same topic: https://bugs.chromium.org/p/chromium/issues/detail?id=705607

The only place where we use client in StatusUploader is, actually, uploading a status, and after that fix (in mid 2017) there is an additional check if client is registered (with a log message if not) before doing anything that required client to be registered.

So, by now, I suppose, we can just remove this DCHECK. Old bug also explains cases when this registered/unregistered unsyncronization may arise.

I don't believe these was anything special about my device -- it had had the same chromeos image for at least a week before, and the account had been present for at least a week as well. The device is a Pixelbook, if that matters.

I'll keep an eye out for this in the next few days while deploying chrome to this same device. If no one else is hitting this, it can definitely be de-prioritized.

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

commit 43132ffeb2245cfc7996e11acfeffb163ab0a380
Author: Oleg Davydov <burunduk@google.com>
Date: Wed Jan 16 10:35:17 2019

Remove check for client registration in StatusUploader ctor

StatusUploader's work makes sence only if working on managed device with
resitered client, but due to some missynchonizations we may not know
if it's registered client when creating StatusUploader. That's why there
is an extra registered check before submitting status. See more in:
https://bugs.chromium.org/p/chromium/issues/detail?id=705607

Therefore check in StatusUploader constructor is redundant and causes
only problems when dchecks are enabled:
https://bugs.chromium.org/p/chromium/issues/detail?id=912770

Bug:  912770 
Change-Id: Ib9c4001b87834286a36cbe3ca123f1c456844ad9
Reviewed-on: https://chromium-review.googlesource.com/c/1400664
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Commit-Queue: Oleg Davydov <burunduk@google.com>
Cr-Commit-Position: refs/heads/master@{#623183}
[modify] https://crrev.com/43132ffeb2245cfc7996e11acfeffb163ab0a380/chrome/browser/chromeos/policy/status_uploader.cc

HI Oleg,
Could you provide steps if this requires manual verification.?

Thanks.!

Hi!

I don't think it requires any manual checks. It was about removing a bogus DCHECK. Old bug 705607 explains why it's bogus (there are some circumstances that are technically valid, but lead to breaking this check, and they were handled in the proper way), and that bag was closed in summer 2017.

DCHECK's are not enabled in release binaries, so I changed almost nothing. Theoretically is't possible (but not easy, even hansberry@, as I can see in comment #5, doesn't know the right conditions) to make a test build, than trigger this check and see that problem (repeating crashes) arises only in old build. But I'm definitely not sure if it's worth of it.

Thanks Oleg, 
Closing the issue as per the confirmation.