Currently for Capri, we don't have particularly robust error handling behavior. As far as I know, this behavior is all there is.
Let's decide what type of error handling we want going forward. This includes scenarios like:
Soil ID request timeout (if request for soil id takes longer than 20(?) seconds, what should happen?)
Elevation request timeout
Database / backend is down
Scope creep: Preventing overwhelming the soil id/backend servers -- may not be relevant yet anyway?
Note: This does not include offline scenarios, as that should be handled as part of the Offline epic
Additional context
Some of these, like Soil ID request timeout behavior, involve deciding what responsibilities belong in the frontend vs. backend
Re: Soil ID timeout: garo is planning to get time durations for the soil id test cases, so we can at least get a sense of how common it may be for soil ID to run for a long time
Description
Currently for Capri, we don't have particularly robust error handling behavior. As far as I know, this behavior is all there is.
Let's decide what type of error handling we want going forward. This includes scenarios like:
Note: This does not include offline scenarios, as that should be handled as part of the Offline epic
Additional context