This should be only if triggered via core:archive command? I reckon not when we archive via API request etc as it would be returned in the API maybe etc. Maybe it would be better to just log such messages and backtrace to a file instead.

There's eg this monolog handler:

From https://github.com/Seldaek/monolog/blob/master/doc/02-handlers-formatters-processors.md :

FingersCrossedHandler: A very interesting wrapper. It takes a logger as parameter and will accumulate log records of all levels until a record exceeds the defined severity level. At which point it delivers all records, including those of lower severity, to the handler it wraps. This means that until an error actually happens you will not see anything in your logs, but when it happens you will have the full information, including debug and info records. This provides you with all the information you need, but only when you need it.

This should be only if triggered via core:archive command? I reckon not when we archive via API request etc as it would be returned in the API maybe etc.

yes, using SettingsServer::isArchivePhpTriggered() should be safe

Maybe it would be better to just log such messages and backtrace to a file instead.

Not sure about instead... would there be an advantage to logging to file? it would be an extra step for users to troubleshoot as they'd need to open the file. Already core:archive output should be sent to admins by email whenever there is an error, so it's nicer not to have an additional step to troubleshoot.

There's eg this monolog handler: FingersCrossedHandler:

this sounds very interesting to log additional debug data, whenever an error has occured! 👍 Could we put this in new issue?

(logging backtrace in core:archive error message still useful IMO even when we have FingersCrossedHandler additionally logging detailed info to file)

Not sure about instead... would there be an advantage to logging to file? it would be an extra step for users to troubleshoot as they'd need to open the file. Already core:archive output should be sent to admins by email whenever there is an error, so it's nicer not to have an additional step to troubleshoot.

Maybe not instead but at least on top. Even a backtrace is often not very helpful to debug those kinda issues...

If it's too hard to access the log files then it shouldn't be too hard to have a "log viewer" in the UI

 Maybe not instead but at least on top. 

+1

Even a backtrace is often not very helpful to debug those kinda issues...

true, but without backtrace (and before you added the plugin name), it was even impossible ;-)

If it's too hard to access the log files then it shouldn't be too hard to have a "log viewer" in the UI

Seems very valuable to add this into LTS #7239 - how much work will it be do you think?

depends on the scope ;) and which library/tool we can use for it... hard to estimate

I'll temptatively move #7239 to 2.15.1 so we can at least think of the scope together - maybe we can KISS and then it'd be for sure high value to have in our LTS version :-)

@tsteur Do you know if the new LogViewer plugin solve this issue, ie. when core:archive fails, could one get the backtrace of the failure directly after installing the LogViewer plugin? are the backtraces logged by default? I guess we need to work on #8695 as well?

No work was done on this so I doubt a backtrace would be logged.

And one can see something in LogViewer only if log to files or databases is enabled