Persist X-Request-ID with the events that originated them

[SamuAlfageme]

X-Request-ID was introduced in client v. 2.4: #5853 for tracing back and cross-referencing requests with the server logs. This can be seen as an extension of that to help users locate the cause of their issues together with admins.

Would it be possible to store this ID together with its originator event on the sync journal to allow some sort of "Copy X-Request-ID` when right-clicking an event from the "Activity > Not Synced" tab? (only in those cases that are strictly related to the server operation/network activity). This way is not strictly necessary to have the log window open or to be inspecting the network to get this ID.

e.g.

sqlite> select * from blacklist;
path        lastTryEtag  lastTryModtime  retrycount  errorstring                                                                                                                     X-Request-ID                                    lastTryTime  ignoreDuration  renameTarget  errorCategory
----------  -----------  --------------  ----------  --------------------------------------------------------------------------------------------------------------------            ----------------------------------------------  -----------  --------------  ------------  -------------
.htaccess                1522758480      2           Server replied "403 Forbidden" to "PUT https://localhost/remote.php/dav/files/admin/.htaccess" (Sabre\DAV\Exception\Forbidden)  4c5adb86-2a66-4450-9af9-f6f77b5bdf581522758593   125                           0

cc/ @michaelstingl

[guruz]

@ogoffart What about adding a column for the in .owncloudsync.log ?
And also modifying the server log templates (for apache, nginx) to show them in the server log file?

[SamuAlfageme]

@guruz

And also modifying the server log templates (for apache, nginx) to show them in the server log file?

Makes complete sense, will open issues/poke people around to do so.

[SamuAlfageme]

Link owncloud-docker/base#22

[SamuAlfageme]

WFM 👍

---

For reference, since @michaelstingl asked me: log rotation period is 2MB - all blacklist errors are meant to re-appear in there, but old errors that went away are not granted to be preserved; an error-only log might be an interesting idea to explore, but a different topic.

client/src/gui/syncrunfilelog.cpp

Lines 96 to 110 in fabc706

	const qint64 logfileMaxSize = 1024 * 1024; // 1MiB
	// Note; this name is ignored in csync_exclude.c
	const QString filename = folderPath + QLatin1String(".owncloudsync.log");
	// When the file is too big, just rename it to an old name.
	QFileInfo info(filename);
	bool exists = info.exists();
	if (exists && info.size() > logfileMaxSize) {
	exists = false;
	QString newFilename = filename + QLatin1String(".1");
	QFile::remove(newFilename);
	QFile::rename(filename, newFilename);
	}
	_file.reset(new QFile(filename));

I fear most of the log contain not-so-useful info, but that's also a different topic:

#=#=#=# Syncrun started 2018-05-17T15:52:45Z
#=#=#=#=# Propagation starts 2018-05-17T15:52:46Z (last step: 857 msec, total: 857 msec)
#=#=#=# Syncrun finished 2018-05-17T15:52:46Z (last step: 12 msec, total: 870 msec)
#=#=#=# Syncrun started 2018-05-17T15:52:48Z
#=#=#=#=# Propagation starts 2018-05-17T15:52:48Z (last step: 322 msec, total: 322 msec)
#=#=#=# Syncrun finished 2018-05-17T15:52:48Z (last step: 36 msec, total: 359 msec)
#=#=#=# Syncrun started 2018-05-17T15:52:59Z
#=#=#=#=# Propagation starts 2018-05-17T15:52:59Z (last step: 267 msec, total: 267 msec)
15:53:03||cv_en.pdf|INST_NEW|Up|1506664574||23909||8|Upload of 23 KB exceeds the quota for the folder|507|0|0|aaa544b5-af30-4d0b-a6d0-18ab07c519a1|
#=#=#=# Syncrun finished 2018-05-17T15:53:00Z (last step: 410 msec, total: 678 msec)

[guruz]

FYI 74e412c 2.5