Skip to content
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

Improve Task Logging #58

Open
mfosterw opened this issue Feb 17, 2024 · 2 comments
Open

Improve Task Logging #58

mfosterw opened this issue Feb 17, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@mfosterw
Copy link
Owner

Right now the same prefix is repeated many times for logging in the tasks.py file. Figure out a way to extract that prefix and place it after all the other prefixes automatically for all logging calls in the module. This is probably best done with a LoggerAdapter. You can see an example here.

@mfosterw mfosterw added the enhancement New feature or request label Feb 17, 2024
@mfosterw
Copy link
Owner Author

This is now less relevant for the tasks module specifically but would be useful for the project as a whole. Along that note, the default format for log messages should be improved (i.e. I don't need process or thread numbers, at least in local)

@mfosterw
Copy link
Owner Author

I have taken a first tilt at this and failed to come up with a satisfying implementation. The issue is that, while it is probably possible to just prepend an extra string to the log message, in all the examples I saw it seems to be an unwritten rule to instead pass context arguments on to the formatter to insert them. However, I don't want to configure a format that depends on models specific to my app. I will probably fix it when I get rid of the django frontend, so I can switch the model __str__ methods to be short representations rather than display names (which now that I've written out sounds like something I might want to differentiate anyway). Once I can confidently call the object.__str__ in the log format, I can add a filter that depends on some general object being defined for the context, which feels much more sensible (e.g. it could be a request at the API level).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant