Replies: 2 comments 1 reply
-
as it is a very old code, can't fully tell about the reasoning behind it. can you come with a draft PR with your findings to see how things go? |
Beta Was this translation helpful? Give feedback.
-
Hello, I've made a small change to try this suggestion (sending to the logger the original exception's
The test suites pass, and as reported in the CONTRIBUTING I've checked that the coverage does not decrease. Thanks |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently in
celery.app.trace
the methodTraceInfo._log_error
is always invoked with an instance ofbilliard.einfo.ExceptionInfo
from which is then extracted theexc_info
to be passed to the logger.This causes a problem because
ExceptionInfo
removes many info from the traceback, expecially thef_locals
variable (which was also reported here celery/billiard#6, yet the code does not copy anything but__traceback_hide__
from the original exception's frame).While there is a reason to keep sending the pickleable version of the exception to queues and to use it the the inter-process communication part of celery, I would like to discuss why not providing the original exception's
exc_info
to the logger? What kind of benefit does celery have with this?Providing the original exception to logger with its original traceback would be more useful to those error-reporting engines which aim to help developers finding and reproducing their bugs.
https://github.com/celery/celery/blame/11eb4d36accc674fed3c87975ba63543abf9d89e/celery/app/trace.py#L242-L270
Beta Was this translation helpful? Give feedback.
All reactions