See the last few comments of Issue 664588 for context.

I agree that surfacing general keyring issues which may cause some profile data to get "corrupted" (in the sense that it can't be decrypted/read) may make sense to surface in the user menu (along with sync errors and auth errors).

My question is what the user can do to recover from those types of errors. Is it as simple as us deleting the old profile data directory and letting their data re-sync back down?

When the particular error is that the encryption key is lost, then yes, deleting the encrypted data and letting sync re-create them is the needed action.

If we add UI to surface this error, we should also present a button for the user to ask Chrome to delete what's needed. In some cases, we could even automate that. For example, if sync is working and Chrome synced up before any modification of the important local data happened, and this issue did not happen too recently (to avoid endless loops), deleting the data should not need user confirmation at all.

You raise a good point. In the cases where we can just silently fix things, we should just go ahead and do that.

What are the cases when some user intervention/action is needed? Why would it be needed? What action would we be asking the user to take?

Note that our error UI in the user menu does include a button.

I think a notification might be useful when the user could lose data because of the local reset. Imagine this situation:
(1) The encryption is working, but the data is not synced (e.g., the user's sign-in credentials are out of data).
(2) The user saves an important password.
(3) Now the user somehow reversibly breaks the encryption by removing the stored passphrase from the Keychain (but still being able to recover it later).
(4) The user updates the sync credentials.
(5) Chrome decides to fix the issue by resetting the stored passphrase in Keychain, removing local encrypted data (including "Login Data", the database with passwords) and syncing.

Here saving works despite broken sync in step (2). If chrome destroys the local data, the user will never be able to recover the password saved in (2), because it was not synced up. However, the user could have been able to recover that password if Chrome did not do step (5) by just fixing the Keychain manually.

In this case, Chrome should allow the user to prevent step (5), by saying something like:
"Cannot decrypt local data. Do you want Chrome to reset it with a copy from Google Chrome sync server? This copy might be slightly out of date. If you keep the old data, password manager and other features may not work properly. [Reset] [Keep]"

I am not sure how realistic this scenario is, step (3) seems to be an edge case. Perhaps vasilii@ as our expert on Mac password storage or cfroussios@ as our os_crypt expert can imagine a more likely scenario? (Other comments also welcome.)

We had examples when (3) happened without user intervention. For some reason Chrome recreated the encryption key. Probably it's a bug in Keyring.
Fixing this particular issue without user mediation is feasible only on startup if we know that Sync worked fine til the previous shutdown.

Regarding the bug.
- I think some error message should appear on chrome://settings/passwords for all the users (not only the power ones).
- May be we could show a button "Send feedback" and prepopulate the report with whatever data we need.

+Sabine

Re #4: It will be very difficult to frame that question in such a way that the user actually understands what's going on well enough to make an informed decision. We may be best off just picking what we think is likely to be the best option for the user at that point.

Related: bug 730625 and bug 479725