borp has a "VersionCol" feature for optimistic locking. We mostly don't use it, but we still have it turned on for the registrations table:

This means that when a registration is read from the database, it gets the current LockCol. When we call Update for that registration, the generated SQL gets a WHERE LockCol = ? clause that specifies the LockCol previously read from the database. And the Update method automatically bumps the LockCol.

We call Update on registration objects in two places:

• UpdateRegistration
• ClearEmail

Since LockCol is a database-internal concept, we don't propagate it in registrationModelToPb; the protobuf version of a registration doesn't include a LockCol, and shouldn't.

In UpdateRegistration, we get around this by reading the current registration, then combining its current LockCol with the data received in the update request protobuf (req *corepb.Registration) to get a regModel with the correct LockCol, then calling Update on that.

However, ClearEmail doesn't do that, meaning that using admin clear-email may fail to clear emails when LockCol > 1. That happens when the user has previously updated their own account using the ACME logs.

Options for fixing:

• In ClearEmail, instead of calling registrationModelToPb, simply parse and modify the contacts field of the fetched registration. Since the registration is staying internal to the SA, converting it to a protobuf is a conceptual mistake.
• In ClearEmail, rather than parsing the contacts field to remove one specific address, clear the whole thing. Accounts can have multiple email addresses, but this is rare, and if a user has asked us to clear one email from their account it's reasonable to clear all of them.
• Remove use of LockCol for registrations. This would require modifications to UpdateRegistration and ClearEmail to replace their Update calls with calls that only touch modified fields (which, can be: contacts; status; or jwk / jwk_sha256 (this one only via the key rotation API).