-
-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error handling for catalog not available 503 #960
Error handling for catalog not available 503 #960
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #960 +/- ##
==========================================
- Coverage 38.58% 38.51% -0.07%
==========================================
Files 108 108
Lines 6223 6244 +21
==========================================
+ Hits 2401 2405 +4
- Misses 3822 3839 +17 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BPerlakiH IMHO you should have a library URL.builder which should be totally disconnected from the libraryView... and then reuse it in your observer. Havin to hardcode URL wherever you need it is not a good sign.
I think it's not that bad as it seems. Formerly we had the url hard coded in a single place in the LibraryViewModel (which is not a view). The only change is that I moved it up higher to the top of the file, so it's easier to find. That's about it, when it comes to the production code. (I also updated the production url to be private for that class). In tests, now I updated to use a mock url, and it works equally good with that as well. The responses are also mocks, which is the key part of those tests, the url can be anything really. To sum up: we do not use the production URL in more than 1 place. |
Fixes: #959
Solution:
Additional enum case for error, and re-use existing translation key for displaying the error.