Blacklist: remember the X-Request-ID

[ogoffart]

Issue #6420
Store the X-Request-ID in the SyncFileItem and also in the blacklist.
Note that for consistency reason, the X-Request-ID is also in the
SyncFileItem if the request succeeds.

Currently there is no UI to access it, but it can be queried with sql
commands

[ogoffart]

I'm a bit concerned about memory usage. Should we only keep the request id in case of faillure?

[SamuAlfageme]

@ogoffart yes, having a QByteArray allocated for each SyncFileItem might be a bit too much (specially after reading the considerations on #5853 (comment) - client currently uses ~42bytes) - I'd say keeping it on memory up until a request resolves and only store it on disk on failure will be a better idea.

And I'd really like to have an option on the UI for inexperienced users (not savvy with sqlite commands) to fetch this info and send it to admins.

[guruz]

I'm a bit concerned about memory usage.

Could avoid this by having the request ID be a crazy hash of the request, path, sync run iteration and PID and some other source. But maybe better not :-)

[ckamm]

Personally I've never used X-Request-ID - putting it in the log I understand, as it doesn't cause other overhead. I don't currently see the ids as particularly useful - am I missing something where they are a huge win?

Storing in the blacklist is fine. But I am worried that we're spending a lot of work on a weak debugging tool.

[ckamm]

Code looks ok

[ckamm]

requestId

[SamuAlfageme]

@ckamm about:

putting it in the log I understand, as it doesn't cause other overhead. I don't currently see the ids as particularly useful

Main concerns I've heard are related to non-persistent-logs setups (user ends up with issues on the "Not Synced" tab but was not using logging). Then he can use those to help the admin/support to correlate and determine which request on the server logs (usually persistent) was responsible for the issue.

cc/ @michaelstingl

[ckamm]

@SamuAlfageme Okay then. It's mostly that I've not personally been in a situation where correlating with server logs was useful and I wanted to understand where the need was coming from.

[ogoffart]

@SamuAlfageme so where exactly do you want these ID to be stored? In which log?

[guruz]

@ogoffart new column in .owncloudsync.log?

[SamuAlfageme]

@ogoffart on #6420 (comment) I thought on using sync journal's blacklist table. As @guruz points out, .owncloudsync.log would also make sense (and will even keep historical data from previous sync runs, even when the error was solved afterwards):

# timestamp | duration | file | instruction | dir | modtime | etag | size | fileId | status | errorString | http result code | other size | other modtime | other etag | other fileId | other instruction | X-Request-ID |
[...]
||Screenshot 2018-04-19 11.52.43.png|INST_NEW|Down|1524131563|2ba3a0df3bd29a417512fe01fce5e522|17901|00000029ocdkxjqy1s03|2|Server replied "403 Forbidden" to "GET https://localhost/remote.php/dav/files/admin/Screenshot 2018-04-19 11.52.43.png"|403|0|0||||4c5adb86-2a66-4450-9af9-f6f77b5bdf581522758593|
[...]

[guruz]

@ogoffart merge this and potentially do a follow up PR?

[guruz]

ˆˆ @SamuAlfageme FYI this is in now