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

commit fedcbd35f0a601ed3e07642673a7ab0e602bee26
Author: tnagel <tnagel@chromium.org>
Date: Fri Jun 02 11:29:41 2017

Improve DeviceSettingsService documentation

BUG=728656

Review-Url: https://codereview.chromium.org/2920833002
Cr-Commit-Position: refs/heads/master@{#476616}

[modify] https://crrev.com/fedcbd35f0a601ed3e07642673a7ab0e602bee26/chrome/browser/chromeos/settings/device_settings_service.h

I believe as long as you make sure all access to status() happens on the same thread as store_status_ is written, it should be fine. Otherwise, you're in trouble. In general, I agree this seems to be bad design.

Since it was me to originally write this code, here is some background: The idea was that interactions with session_manager would not only indicate status of the operation, but also about the state the system is in. E.g. STORE_KEY_UNAVAILABLE triggers PERMANENTLY_UNTRUSTED status, and a successful store operation updates that to TEMPORARILY_UNTRUSTED / TRUSTED. So the status of an operation *does* have a meaning for the overall system status as observed from Chrome. Since all operations happen asynchronously and there's no way around that, the risk of race conditions is inherent and you'll not be able to fix that. I'd agree though that it'd be nice to have a way to determine the status of an individual operation if that is useful (is it?).

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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