Yeah I wasn't sure what to say. I'm struggling to understand why this diff was submitted.

The product functionality needs to be remain unchanged. Existing Ethereum accounts should not go through the registration flow. There's no world where we can just "break" this. It feels like you're trying to avoid work because you hadn't scoped it previously.

The auth / unauth stuff also makes no sense to me. Isn't the whole point of @will's work to move exactSearchUserCall to the identity service?

In D11016#318095, @ashoat wrote:

Yeah I wasn't sure what to say. I'm struggling to understand why this diff was submitted.

ok, not sure how just pushing it back to my queue was productive, though...

The product functionality needs to be remain unchanged. Existing Ethereum accounts should not go through the registration flow. There's no world where we can just "break" this. It feels like you're trying to avoid work because you hadn't scoped it previously.

you're right, i should have scoped this better. i'll think more about how to avoid breaking the existing product functionality.

The auth / unauth stuff also makes no sense to me. Isn't the whole point of @will's work to move exactSearchUserCall to the identity service?

my understanding was @will's work moves searchUsers to the identity service, but it seems reasonable to use that work for an exact user search, too. however, it's also currently designed as an auth API, so it won't work without a CSAT

Ah so the API is already built then, and just needs to be moved between protos. Great

Should we "fall back" to the legacy workflow if the new one doesn't work?

In D11016#320731, @ashoat wrote:

Should we "fall back" to the legacy workflow if the new one doesn't work?

we have a new plan instead of a fallback mechanism including automated alerts, daily manual testing, and an opt-in mechanism for clients to inform us when there are issues