Open AIexanderDicke opened 2 weeks ago
Thanks for your proposal. I think that in general it is better to leave the logging to the client of the library, for example listening to the proper events you should be able to produce the logs for those things that you are interested of. The reason being that some users may not want to spend time calling a log function if they want to maximize performance. The examples that you pointed out I think should actually be removed as I can see we are emitting an error when they happen. It is probably the left-overs of some debugging which was overlooked when reviewing a PR. A middle ground could be to have a special pluggable Logger functionality that can be attached to a Worker or Queue class and listens to the events and output logs, in this way it could be choosen by the user when needed.
At the moment, the python library has no logging. Errors are simply printed to stdout (e.g. here or here). This makes it very difficult to monitor an application that uses BullMQ.
Some examples of logs to add (always assuming
logger = logging.getLogger(__name__)
):Remove the printing of exceptions and instead log on error level. For example, change this line to something like
Even better might be something more informative like
Add basic job logging on info (or maybe debug) level, e.g. by adding something like
to the
Worker.processJob
method.Add logs for adding jobs to a queue, maybe something along the lines of
I would be happy to implement this, if there are no objections to these changes!