ui: simplify network error handling#23431
Conversation
allozaur
left a comment
There was a problem hiding this comment.
Hey! It's a great opportunity to do a bit more in-depth refactor of error handling :) I was planning to have dedicated error classes for different types of errors in the app in order to have this properly structured and more easily debuggable.
Are you up to it? Or you'd rather focus on just shipping this one improvement?
|
I'm not sure if I'd be capable of refactoring this properly - I have absolutely never ever dealth with Svelte, and I don't have a proper environment for huge modifications (this was done on a GPU-equipped machine via SSH and Ideally I'd prefer to have this merged (specially to fix the error regarding improper error reporting with |
Okay, no pressure, will get back to this PR tomorrow then. |
|
I've took care of all the issues, except the EDIT: I stand corrected - I forgot how unserious JS is and discovered you can apparently just I made |
fa0f0f3 to
aaca5ac
Compare
|
@socram8888 plz fix the linting/formatting so that the CI checks pass :) |
|
@allozaur should be GTG now. |
some checks still not passing 
|
|
@allozaur I had missed the |
|
@socram8888 hmm, linting is still not passing on the CI here on GH, please re-check |
|
@socram8888 let's aim to have this merged soon :) please let me know if u can take care of the CI failing on linting |
allozaur
left a comment
There was a problem hiding this comment.
Let's fix the lint in CI
Previously error to string conversion was split in two different files, with one converting errors into strings, and another function analyzing those strings to generate yet another string. Now the the error handling for network fetches has been centralised and uses directly HTTP error codes whereas possible to generate the human-readable error strings. It also fixes an issue where all JSON errors reported from the backend, such as "Invalid API key", would get turned incorrectly in to "Failed to connect to server" due to poor matching logic in the now-gone getErrorMessage function.
|
@allozaur Done. Both |
Previously error to string conversion was split in two different files, with one converting errors into strings, and another function analyzing those strings to generate yet another string. Now the the error handling for network fetches has been centralised and uses directly HTTP error codes whereas possible to generate the human-readable error strings. It also fixes an issue where all JSON errors reported from the backend, such as "Invalid API key", would get turned incorrectly in to "Failed to connect to server" due to poor matching logic in the now-gone getErrorMessage function. (cherry picked from commit 69cea5b)
Previously error to string conversion was split in two different files, with one converting errors into strings, and another function analyzing those strings to generate yet another string. Now the the error handling for network fetches has been centralised and uses directly HTTP error codes whereas possible to generate the human-readable error strings. It also fixes an issue where all JSON errors reported from the backend, such as "Invalid API key", would get turned incorrectly in to "Failed to connect to server" due to poor matching logic in the now-gone getErrorMessage function.
Previously error to string conversion was split in two different files, with one converting errors into strings, and another function analyzing those strings to generate yet another string. Now the the error handling for network fetches has been centralised and uses directly HTTP error codes whereas possible to generate the human-readable error strings. It also fixes an issue where all JSON errors reported from the backend, such as "Invalid API key", would get turned incorrectly in to "Failed to connect to server" due to poor matching logic in the now-gone getErrorMessage function.
Previously error to string conversion was split in two different files, with one converting errors into strings, and another function analyzing those strings to generate yet another string.
Now the the error handling for network fetches has been centralised and uses directly HTTP error codes whereas possible to generate the human-readable error strings.
It also fixes an issue where all JSON errors reported from the backend, such as "Invalid API key", would get turned incorrectly in to "Failed to connect to server" due to poor matching logic in the now-gone getErrorMessage function, as any error not contemplated by the
.includes()would fallback to that generic confusing error message.