graceful handling of 500 response

[brainchild0]

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:

1. Terminate the operation.
2. Continue the operation by processing other items in spite of the error related to a specific item.
3. Display an error symbol in the toolbar icon.
4. Display the specific error text in the configuration pane.

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]

Do you currently have this problem? Floccus should actually terminate once it hits a server error.

[brainchild0]

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]

This might be due to the speedup option, which is enabled by default. Can you try disabling it?

[brainchild0]

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]

Ah, that's alright. The default state of the speedup option has changed in the meantime.

[marcelklehr]

Is this still a problem for you? I haven't been able to replicate this, sadly.

[brainchild0]

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:

Trying to insert an already existing item into OrderTracker: folder:NHg-uKK_X1ul

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]

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.

Trying to insert an already existing item into OrderTracker: folder:NHg-uKK_X1ul

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]

I don't think it's optimal to continue syncing if the server returns an unexpected Error

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]

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]

In any case, in the latest release candidate, see #666, floccus should no longer hang indefinitely.