New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When archiving fails with a SQL exception, also output the plugin name in the exception message to help troubleshooting #8600

Closed
mattab opened this Issue Aug 19, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@mattab
Member

mattab commented Aug 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tsteur

tsteur Aug 21, 2015

Member

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)...

Member

tsteur commented Aug 21, 2015

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)...

@tsteur tsteur closed this in #8604 Aug 21, 2015

@mattab

This comment has been minimized.

Show comment
Hide comment
@mattab

mattab Aug 21, 2015

Member

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

Member

mattab commented Aug 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tsteur

tsteur Aug 21, 2015

Member

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.

Member

tsteur commented Aug 21, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment