[ADR] Graceful Device Initialization Failure Handling #230
Conversation
nateinaction
changed the title
|
|
Hey @nateinaction! Thanks for putting this together and this is a great way to document decision points going forward. I added a tag that can be used for these kinds of issues so we can go back to them in the future easily. After spending some time thinking about the two options, I think Option #2 would be preferable to try and maintain the highest level of code safety without putting too much of a burden on the end user. Especially because the expectation is that this codebase will primarily be used by beginner software teams with very limited resources, creating a system where it is unlikely or impossible that downstream function calls might become an unhandled exception minefield feels like it should be a top priority. In my mind one of the other potential benefits of going with the second option is making it easier to implement a "Circuit Breaker Pattern" type of thing to allow downstream services to still call into something which has built in functionality to try and restore the connection to the downstream sensor over time. |
|
|
||
| ### Pattern 1: Generic Device Protocol with `get_state()` | ||
|
|
||
| We propose to add a `get_state()` method to the generic device protocol. This method will return 1 of 3 possible states: `unknown`, `initialized`, or `failed` allowing downstream services to check the state of a device before attempting to use it. |
There was a problem hiding this comment.
| We propose to add a `get_state()` method to the generic device protocol. This method will return 1 of 3 possible states: `unknown`, `initialized`, or `failed` allowing downstream services to check the state of a device before attempting to use it. | |
| We propose to add a `get_state()` method to the generic device protocol. This method will return 1 of 3 possible states: `disabled`, `enabled`, or `failed` allowing downstream services to check the state of a device before attempting to use it. |
|
Summary
This pull request introduces a new Architectural Decision Record (ADR) for handling safe device failures on the satellite. The ADR proposes patterns to replace the now removed
hardwaredictionary that used to track device initialization state.