During EF 26 the app began failing to parse the response due to the absence of a value in the Text key for knowledge entries. While we fixes this during the con we only found out there was an issue due to an attendee coming to us. Having some automation to run this check for us would be much safer for next time.
Proposal:
Expose an error from API.fetchLatestData's completion handler (i.e. it spits out a Result<ModelCharacteristics, Error> instead of ModelCharacteristics?). In the negate case, the model bails out the update process as it currently does
Include an acceptance test that uses the real API, configured the way the app does so, that can check if we actually receive a response and not an error. This should always pass but we accept there may be a few cases it does not - e.g. the CI environment has a network blip. It should fail when the model changes in such a way the response becomes incompatible with the app.
Include the test in the pipeline validation checks, and include an automated workflow for the month during the convention to run the test nightly. We could increase its frequency during the convention to catch any in-situ updates that might break the app
We could also potentially post failures to a Telegram channel to keep us on top of things.
During EF 26 the app began failing to parse the response due to the absence of a value in the
Text
key for knowledge entries. While we fixes this during the con we only found out there was an issue due to an attendee coming to us. Having some automation to run this check for us would be much safer for next time.Proposal:
API.fetchLatestData
's completion handler (i.e. it spits out aResult<ModelCharacteristics, Error>
instead ofModelCharacteristics?
). In the negate case, the model bails out the update process as it currently doesWe could also potentially post failures to a Telegram channel to keep us on top of things.