With the changes from df006bb348, the requested download queue data changed not matching the previously used type.
The unnecessary cast then hid the tsc issues during compilation
In case the "depth" of the initial opened app page was greater than 2 it was possible to get stuck in a loop of using the back button twice from the initial page to the previous page and back to the initial page...
Instead, in case a page with a greater depth than 0 is opened, the library should just be opened when using the back button.
This way the back button actually behaves like it's intended, as an app back button and not like the browsers back button
It's possible that the "trackProgress" mutation of the "updateChapters" mutation fails, which then would lead to the "mark as read" and "delete chapter" mutation data to be omitted, thus, preventing the cache from being updated with the received mutation data response
Makes more sense compared to the previous logic - to only show the scanlator in case "skip dupe chapters" setting was disabled and duplicated chapters existed - which was also not properly implemented, to be always able to tell if chapters of different scanlators might be viewed
In case "skip duplicated chapters" is enabled and the next chapter is from a different scanlator, the initial opened chapter should still be used to remove duplicated chapters.
Otherwise, the original scanlator would get lost and the scanlator of the next chapter would get used, which was only a fallback chapter, because the initial chapters scanlator did not have a next chapter.
It's possible that the queue only contains a failed invalid (does not exist anymore in the database) chapter which then causes graphql errors.
In this case the queue was considered empty which prevented it from getting cleared.
Without being able to clear it, the error could not be fixed.
The local server settings were not shown in case the actual server settings were loading or the request failed.
E.g. in case the "server url" was set to an invalid url, it was not possible to correct it again
Server settings request loading and error state were never handled, thus, in case this request was still loading or failed, instead of showing the proper page state, the missing repo info was shown
