Use the "s:message" from erroneous requests on their "Issue" column #6459
Assignees
Labels
Milestone
Comments
|
Normally this was already supposed to be the case. AbstractNetworkJob::errorStringParsingBody is supposed to extrace the Message. |
ogoffart
added a commit
that referenced
this issue
Apr 17, 2018
ogoffart
added a commit
that referenced
this issue
Apr 18, 2018
|
@ogoffart can't see this working on latest nightly, might be missing something 😕 With the steps from my original #6459 (comment) (the one for fetching files with oauth2 + user-key encryption enabled owncloud/oauth2#105) I'm still seeing the long "issue" text. |
|
Seen w/ files firewall as well - in that case; there's a bogus timer as well: i.e. does not update reactively. |
|
blue-ticket, moved into milestone |
ogoffart
added a commit
that referenced
this issue
May 30, 2018
We want to keep the body so we can get the message from it (Issue #6459) TestDownload::testErrorMessage did not fail because the FakeErrorReply did not emit readyRead and did not implement bytesAvailable.
ogoffart
added a commit
that referenced
this issue
May 31, 2018
We want to keep the body so we can get the message from it (Issue #6459) TestDownload::testErrorMessage did not fail because the FakeErrorReply did not emit readyRead and did not implement bytesAvailable.
ogoffart
added a commit
that referenced
this issue
Jun 1, 2018
We want to keep the body so we can get the message from it (Issue #6459) TestDownload::testErrorMessage did not fail because the FakeErrorReply did not emit readyRead and did not implement bytesAvailable.
|
Still reproducing in today's daily build w/ the files firewall 403
|
|
Strange, this works for me with the file firewall on linux. |
|
@ogoffart from |
|
Ah, the patch was not in the alpha. |
|
@ogoffart with
For some reason it also displays a bogus progress value (i.e. 2KB) and creates hidden zero-byte file " |
So you are saying the sync looks like it continues even though there is errors? CC @ckamm for blacklist stuff |
|
It actually never starts - not sure how 2.5alpha1 and master diverged re. this. Also I remember @ckamm and I discussed the 0B Disclaimer: the firewall reproducer might not be the best. |
|
Blacklist: If the correct error message is shown to the user the first time, the same message will also be shown on subsequent runs when the file is ignored. So blacklisting isn't supposed to affect which error is shown - except that the message will only be updated if there is an actual synchronization attempt for the item. |
|
@SamuAlfageme I see the same odd gui state that you show in your screenshot on the 2.5 branch (white text "preparing to sync" that doesn't go away) - let's cover that in a different ticket though: #6581 The download temporaries I'd not worry about. They exist because there's a download error and should go away when it is resolved. |
|
I have tested that again, and i see the message properly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was just testing the fix in owncloud/core#29794 (comment) and realized we could rethink the way client/server errors get displayed:
The "Issue" on the "Not Synced" tab reads as follows:
Which does not contain the actual reasons for the issue. On the body of the response we have more info of the actual problem:
Replacing the full WebDAV path that failed (not that useful since the user already has this info in the "File" entry) by the
s:messageon the reply would be more useful and somehow user-friendly.Of course, if said response does not contain such
s:message, we can use the old logic as fallback.The text was updated successfully, but these errors were encountered: