You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure how to deal with this most elegantly – I feel like we'll have to pass thread/task objects into the event_dict or something?
I think the process_name is in fact correct, since logging just sets it unconditionally and we get n/a in sync code too. Happy to be corrected, though.
The text was updated successfully, but these errors were encountered:
@hynek Just thinking quickly aloud, maybe a possible solution will be to pass some context about the origin of the respective log method calls using contextvars when the "async-to-sync" proxy is called? What I mean in short is to try to use/simulate the function asyncio.to_thread() included in the standard lib as of Python 3.9 which (I'm quoting the official documentation):
Also, the current contextvars.Context is propagated, allowing context variables from the event loop thread to be accessed in the separate thread.
The main advantage of this is that it'll be totally thread-safe/async task-safe.
What do you think? Does it sound feasible to you?
By the way, regarding this ...
I think the process_name is in fact correct, since logging just sets it unconditionally and we get n/a in sync code too. Happy to be corrected, though.
Yes, you're right! All ok from my point of view as well. Anyway, the solution above should also be able to cover the original process_name indeed.
This is based on @PrieJos's helpful analysis in #693 (comment)
In async log methods, callsite collection happens in the async logger thread which makes its thread-related information worthless:
Notably, thread name is wrong and so would be a task name as shown in #698:
Not sure how to deal with this most elegantly – I feel like we'll have to pass thread/task objects into the event_dict or something?
I think the
process_name
is in fact correct, sincelogging
just sets it unconditionally and we getn/a
in sync code too. Happy to be corrected, though.The text was updated successfully, but these errors were encountered: