Thanks, Ben! Ryan, can you take a look at the logs? Despite the feature state map looking like:

{
  Featur<IPv6: 3>kBetterTogetherSuite: FeatureStat<IPv6: 3>kEnabledByUser,
  Featur<IPv6: 3>kInstantTethering: FeatureStat<IPv6: 3>kEnabledByUser,
  Featur<IPv6: 3>kMessages: FeatureStat<IPv6: 3>kEnabledByUser,
  Featur<IPv6: 3>kSmartLock: FeatureStat<IPv6: 3>kEnabledByUser,
}

I still see logs like:

[8850:8850:1202/193929.500913:INFO:easy_unlock_service_regular.cc(183)] Smart Lock is disabled; aborting.

I also see hard lock present for sign in:

[8850:8850:1202/193836.056403:INFO:easy_unlock_service_signin_chromeos.cc(433)] Hardlock present, skipping remaining login flow.

The discrepancy Jeremy pointed out is very odd: 

Featur<IPv6: 3>kSmartLock: FeatureStat<IPv6: 3>kEnabledByUser,
...
"Smart Lock is disabled; aborting."

This log shouldn't be printed if state truly is kEnabledByUser: [1]. I may need to locally checkout the 71 branch to investigate if this was an old logic bug that has since been fixed. I'll loop back when I do so. 

1) https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/easy_unlock/easy_unlock_service_regular.cc?q=%22Smart+Lock+is+disabled;+aborting%22&sq=package:chromium&g=0&l=161

Turns out it is now working ... I thought you must have done something but maybe it was the update to 72 that kicked it into a working state.

FWIW I have found the UI of clicking the picture a bit weird, but that's another matter.

Another data point: dcavalcanti@ hit this issue on January 5, on 71.0.3578.98 [1]. No logs yet; waiting to hear back.

1) https://groups.google.com/a/google.com/forum/#!topic/chromeos-discuss/wIt7AYHj5jk

Upping priority. It's still unclear if this is affecting most users.

Addendum to previous comment: it's also unclear if this only affects M71 or more recent versions. If this only affects M71, then unless the issue is severe enough to merit a merge fix into stable-channel, there won't be much to do here. I'll keep my eyes peeled to see if anyone else reports a similar issue.

Logs attached, right after reproducing issue.

71.0.3578.98 (Official Build) (64-bit)

Deleted: proximity_auth_logs_2019-01-08T02_13_38.194Z.txt 15.9 KB

proximity_auth_logs_2019-01-08T02_13_38.194Z.txt 15.9 KB View Download

Thanks Diego!

Diego's logs look pretty similar to the original report. They read:

  Feature::kBetterTogetherSuite: FeatureState::kEnabledByUser,
  Feature::kInstantTethering: FeatureState::kDisabledByUser,
  Feature::kMessages: FeatureState::kEnabledByUser,
  Feature::kSmartLock: FeatureState::kEnabledByUser,

and later:

  23:12:34.229 easy_unlock_service_regular.cc:183 Smart Lock is disabled; aborting.

Just like Comment #1. Even stranger, Smart Lock appears to successfully connect with the host device via BLE after these logs (it shouldn't be doing this if it's truly disabled). 

Perhaps something is wrong in EasyUnlockServiceRegular which makes it incorrectly believe "Smart Lock is disabled"? I'm looking at the code path now [1], and my first guess is that something may be wrong with legacy mode behavior. Still investigating.

Diego, can you describe (or attach a screenshot) of how Smart Lock visually behaved at the lock screen when you reproduced this? Did it display an icon, and was that icon animated in any way?

1) https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/easy_unlock/easy_unlock_service_regular.cc?q=easy_unlock_service_regular.cc:183&sq=package:chromium&g=0&l=154

There's no icon at all. All it shows is the attached message saying Smart
Lock will work next time, which never happens.

On Tue, Jan 8, 2019, 17:47 hansberry via monorail <
monorail+v2.3008606467@chromium.org wrote:

Hi Diego, thanks for the additional info. Do you mind resending the attachment? It looks like it got corrupted or lost in some way.

Do you mind trying something for me? Can you do the following:
1) Sign out and sign back in.
2) Lock the screen, note the exact language of the text (screenshot is fine if you'd like). Enter password to unlock.
3) Repeat step 2 two more times, making sure that you determine if the language is subtly different, or exactly the same, between attempts.

I believe I've found why this issue would occur on an initial unlock attempt, but I'm still uncertain why this issue can reproduce on consecutive attempts. If I know the exact language you're seeing and whether it repeats or a new message appears, that will help me a lot in tracking this down!

Ah, sorry, I didn't notice the screenshot had been dropped from my reply.

The error message I see is the following:

"To start Smart Lock, enter your password. Next time, you can use your phone to unlock your Chromebook."

Except that every single time I lock my Pixelbook, it shows the same. I've just tried unlocking and locking it four times, all with the same message.

I'm attaching more recent proximity-auth logs.

Deleted: proximity_auth_logs_2019-01-09T02_17_56.211Z.txt 40.1 KB

proximity_auth_logs_2019-01-09T02_17_56.211Z.txt 40.1 KB View Download