@mattab opened this Issue on August 19th 2015 Owner

when running scheduled archiving, via the core:archive command, sometimes one of the sub-processes fails.

Here is an example error we got on production: ERROR [2015-08-19 16:06:42] Got invalid response from API request: ?module=API&method=API.get&idSite=191124&period=day&date=last52&format=php&trigger=archivephp. Response was 'a:2:{s:6:"result";s:5:"error";s:7:"message";s:32:"Invalid bind-variable name ':00'";}'

The challenge is that we do not know where this error was triggered. It could be in core, in a core plugin, or in any third party plugin used by this server.

Suggestion:

  • can we display in the error message, the plugin name that triggered this error?
    • this is similar to our recent improvement that displays the plugin name in the SQL query itself as a SQL comment: #7913

What do you think?

(adding to LTS since it will help troubleshooting very much!)

@tsteur commented on August 21st 2015 Owner

BTW: I'd recommend to always keep the log on for archiving then it will be even easier to debug such things (writing to file only). Maybe we need the possibility to define different log writers for different areas (archiver, tracker, UI)...

@mattab commented on August 21st 2015 Owner

BTW: I'd recommend to always keep the log on for archiving then it will be even easier to debug such things (writing to file only)

Oh, you remind me that in core:archive, when the API response was an error, it used to always include the backtrace. This way we knew, from the user/client report, directly the backtrace that caused the fatal error...

Maybe we need the possibility to define different log writers for different areas (archiver, tracker, UI)...

Not sure if I got your point, but it's true that we can make troubleshooting even easier, created this issue: When an API request fails during archiving (core:archive), output the backtrace in the error message #8616

@tsteur commented on August 21st 2015 Owner

My point is that you want log_writers = screen,file; log_level = warn in UI, log_writers = file, log_level=INFO in archiving and maybe sometimes log_writers=file, log_level=DEBUG when tracking to be actually able to trouble shoot things afterwards.

Logging is an important part of an application and it should be on by default, especially for archiver, and write to file. Just having the plugin name in the exception message won't help you much.

This Issue was closed on August 21st 2015
Powered by GitHub Issue Mirror