1679816 - Phabricator emails: Handle API version mismatches during upgrades

Status: NEW

(Conduit :: Phabricator, enhancement, P3)

Description

[Mitchell Hentges [:mhentges] 🦀]

After a brief chat with Ops, it sounds like Phabricator and phab-emails are upgraded independently of each other. Therefore, it's possible that a new (or old) version of phab-emails may request emails from a new (or old) Phabricator and choke on the reponse.

There's four solutions I've considered so far:

1. Just smile and drop emails when the format when an API version mismatch happens (current solution, will have larger impact when phab-emails is out of beta)
2. Write phab-emails (or Phabricator) defensively to support API version mismatches (e.g. a temporary migration layer). Adds an extra mental burden (did we remember to support <prev version>?) and testing burden (did we remember to QA before we upgraded Phabricator and after we upgraded Phabricator?)
3. Turn off phab-emails while doing upgrades, turn on phab-emails when both it and Phabricator are updated, then let phab-emails catch up. In this case, phab-emails will always be API compatible with Phabricator, since it will not be making requests while there's uncertainty between versions. This solution was brought up with ops, and it doesn't sound viable for them (it doesn't match existing workflows, requires manual steps)
4. Explicitly define API version in phab-emails and Phabricator, throw out emails and retry if the versions don't match up.

Out of these, I like solution 4 the most.

Comment 1

[Mitchell Hentges [:mhentges] 🦀]

This ticket has more value if there's a lot of API migrations happening.
However, we're nearing the roll-out of phab-emails, and most of the API changes are already complete.
So, I'm going to de-prioritize this and remove it from blocking the official rollout.

If we want to do this in the future, it's still a valid improvement, but it's just not helpful enough to do right now.