|
| 1 | +# ADR 002: Remote kills are absolute |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +Accepted |
| 6 | + |
| 7 | +## Context |
| 8 | + |
| 9 | +When rapidly iterating on API for prerelease features, we will commonly |
| 10 | +want to make breaking API changes without revving the API endpoints and |
| 11 | +maintaining the previous versions of the endpoints indefinitely for |
| 12 | +versions of the app that will never be seen by customers. |
| 13 | + |
| 14 | +In that context, remote kills stand to be an incredibly useful tool. |
| 15 | +When you decide to make a breaking API change, you simply create/update |
| 16 | +a remote kill for the app from version `0` through the first client |
| 17 | +version conforming to the new contract. Then, instead of getting crash |
| 18 | +bugs on dev builds, the feature simply turns itself off, and testers |
| 19 | +will have to upgrade in order to see the feature again. |
| 20 | + |
| 21 | +This stands to eliminate false bug reports of crash bugs from |
| 22 | +internal/alpha testers who simply need to upgrade. |
| 23 | + |
| 24 | +But if we want to rely on this as a safety mechanism, we need to make |
| 25 | +sure that chrome extension assignment overrides don't have the |
| 26 | +opportunity to win-out over a remote kill, because they are too blunt of |
| 27 | +a tool. As an alpha tester, you might see that the feature went away and |
| 28 | +perform another override in the Chrome extension. If that happens, |
| 29 | +you'd be back in crash bug land. |
| 30 | + |
| 31 | +## Decision |
| 32 | + |
| 33 | +On TestTrack server, remote kills will be absolute and won't be |
| 34 | +overridden by force assignments regardless of the relative recency of |
| 35 | +the override and the remote kill. |
| 36 | + |
| 37 | +## Consequences |
| 38 | + |
| 39 | +As a result, it may be somewhat more difficult for app developers to |
| 40 | +"see around" an open-ended remote kill that was dropped because of a bug |
| 41 | +as they work on the bugfix. |
| 42 | + |
| 43 | +A hypothetical solution is to bump the app version on their branch and |
| 44 | +then mark the remote_kill's fixed_version as that version, so that as |
| 45 | +they develop the fix, their local builds will allow them to see their |
| 46 | +work. Then merging and releasing the branch will cause the fix to be |
| 47 | +available to consumers of that build. |
| 48 | + |
| 49 | +This might introduce version number linearization problems unless we |
| 50 | +hold all other merges until the bugfix is released, which may or may not |
| 51 | +be an issue the dev team can stomach. |
| 52 | + |
| 53 | +As an alternative, we could make the forthcoming fake TestTrack server |
| 54 | +being developed into the Rails client less draconian, and allow |
| 55 | +assignment overrides to take precedence over remote kills in that |
| 56 | +context only. Then the remote_kill fixed_version could be stamped once |
| 57 | +the release version of the bugfix is known, after the developer has |
| 58 | +already locally tested the fix. |
0 commit comments