mirror of
https://github.com/floccusaddon/floccus.git
synced 2026-04-26 22:55:59 +03:00
[GH-ISSUE #429] graceful handling of 500 response #328
Labels
No labels
browser-specific
bug
correctness issues
enhancement
feature: Google Drive
feature: Linkwarden
feature: git
feature: nextcloud-bookmarks
feature: tabs
feature: webdav
help wanted
native-app
priority: high
priority: low
priority: medium
pull-request
question
question
stale
upstream
waiting for more information
wontfix
🙁 Not following issue template
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/floccus#328
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @brainchild0 on GitHub (Jan 12, 2020).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/429
As described in #360, when floccus encounters a HTTP response code 500 (internal server error), it hangs indefinitely.
While the root cause of the error response is often unrelated to any problem in the client, numerous incremental improvements would enhance the usability of floccus while handling this condition.
Some ideas are the following:
In addition merely to enhancing usability, providing accurate information about the server problem through the client reduces the likelihood of the user unhelpfully reporting issues in the client following problems originating from errors on the network side.
@marcelklehr commented on GitHub (Jan 12, 2020):
Do you currently have this problem? Floccus should actually terminate once it hits a server error.
@brainchild0 commented on GitHub (Jan 12, 2020):
My recent observation was that the operation hung indefinitely. I repeated several times, each of which I terminated manually after several hours by cycling the enabled state of the add-on in the browser.
I am currently running version 3.5.3 under Firefox 72.0.1 built for Linux Mint (mint- 1.0).
@marcelklehr commented on GitHub (Jan 13, 2020):
This might be due to the speedup option, which is enabled by default. Can you try disabling it?
@brainchild0 commented on GitHub (Jan 13, 2020):
The option Speed up synchronization was disabled by default, and I never altered it. It is and has always been disabled. Do I misunderstand?
@marcelklehr commented on GitHub (Jan 13, 2020):
Ah, that's alright. The default state of the speedup option has changed in the meantime.
@marcelklehr commented on GitHub (Jun 27, 2020):
Is this still a problem for you? I haven't been able to replicate this, sadly.
@brainchild0 commented on GitHub (Jun 28, 2020):
Currently, the sync operation never terminates or expresses an error, when I run in my browser.
Floccus shows messages of the following kind in the popup window, but without writing any clarification to the log:
Concerning replicating the issue, of course, the question is not whether the server returns an error, but how an error code is handled by the client. Optimally Floccus would continue syncing other items in the same operation, even if some fail, and then would make the full error message available in the application whenever the user wishes to see it.
@marcelklehr commented on GitHub (Jun 28, 2020):
I don't think it's optimal to continue syncing if the server returns an unexpected Error as lots of unexpected things may follow. I tend to follow the philosophy "Fail fast", while of course trying to avoid failing at all.
This is good news! I added that assertion recently to catch a specific type of error early. Would you mind providing your log via my file drop?
@brainchild0 commented on GitHub (Jun 29, 2020):
It may seem as such, but it is important to consider the full breadth of reasons for an error.
In the case that originally prompted me to open this report, I had added several bookmarks on the client, one of which had an emoji in the title text. Since the backend database lacked support for 4-byte characters, the Nextcloud instance rejected the request to add that item. The rejection was not graceful, but rather the infamous fallback 500 code.
It seems clear in this case that continuing the operation for the other bookmarks is preferred. Otherwise, a rejected bookmark may sit in the middle of a sequence of several, the previous ones already having been added successfully, and the remaining ones prevented from being processed by the single offending item in the middle.
Ultimately, a better client may depend on a better server. If the client is unable to make useful decisions following a failure due to lack of information in the response about the reason of the failure, then the issue might be passed to Nextcloud for consideration over enhancements in error reporting. My guess is that the database operation in the Nextcloud request handler triggered an uncaught exception that the web server reported as 500, because no clearer behavior was available.
But the current limitations on the server may not provide a good reason to assume a "fail fast" strategy on the client, as you suggest.
@marcelklehr commented on GitHub (Oct 12, 2020):
Indeed, fail fast may not be the best approach in this case. However, it is not easier to programmatically identify this error on the server, as the DB query simply fails. Ultimately, if a DB query fails, this indicates that your setup is broken and it should return a 500, IMHO. Gracefully ignoring this setup mistake may be useful in the short term, but in the long term, I don't want to encourage users to ignore a setup issue. I think it would be a better strategy to make it easier to identify the setup issue by displaying a warning on the server, like the News app does in this specific case.
@marcelklehr commented on GitHub (Oct 12, 2020):
In any case, in the latest release candidate, see #666, floccus should no longer hang indefinitely.
@brainchild0 commented on GitHub (Oct 12, 2020):
Stopping immediately and returning with a success status are not the only two options. A third possibility is to continue with the other items, and then return a non-success status (which may be warning if not error). Then the user would receive the fullest possible benefit of the operation and still would have useful information about the failed item in the operation.
Yes, the client should report as much as possible from the server, and if too little information is available to be useful for real users, then this lack is an issue that may be passed upstream to the server development group. Some very specific problems may not be identifiable programmatically, because it is impossible to anticipate all possible causes of failure, but any error strings or other human-readable information is useful because it eliminates the need to look through the server logs.
@marcelklehr commented on GitHub (Oct 29, 2020):
I realize there's a lot that could be improved in this situation. Server error messages are now displayed in the floccus UI. I'm closing this for now as I think there are issues with higher priority.
@github-actions[bot] commented on GitHub (Mar 21, 2023):
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.