Log forwarding

[cretz]

What was changed

• Added temporalio.runtime.LogBuffer which can be created for runtime and have retrieve_logs called on it
• Added temporalio.runtime.LoggingConfig.buffer option to accept the above buffer
• Added Rust code to performantly pass through core logs to the caller when they call retrieve_logs
• Update pyo3 to 0.19 and added pythonize dependency to go from serde log fields to Python object
  • After some internal thought, the tiny size of that library coupled with the benefit of having additional fields was deemed worth it over converting to JSON on Rust side and from JSON on Python side. But can be convinced otherwise.

Checklist

1. Closes [Feature Request] Log Forwarding Support for python-SDK #311

[bergundy]

Not sure how you're expecting users to use this. Are they supposed to fetch the buffered logs and feed those into their logger periodically?

[cretz]

Not sure how you're expecting users to use this. Are they supposed to fetch the buffered logs and feed those into their logger periodically?

Yes, same for buffered metrics (we even named everything the same). I could provide a default implementation for Python logging, but I hesitate to have a default frequency + asyncio-based sleep.

[bergundy]

This isn't a good experience IMHO, we should be helping users collect these logs and make sense of the ordering between core and python logs.

[cretz]

This isn't a good experience IMHO, we should be helping users collect these logs and make sense of the ordering between core and python logs.

I disagree, I think we should give the user the ability to collect the logs and do what they want. This is the same with metrics buffering, it's just log buffering.

If we want to add layers on top to integrate with existing metrics systems or existing logging, I think that is a separate addition to this foundational piece. Not something that should block this piece

[Sushisource]

I agree with Roey that this should be easier for users than having to do it themselves. I also think it's fine to not block the PR, but, releasing just this seems nowhere near as nice as releasing with the fully integrated version like TS has. It's not much extra to add either.

[Sushisource]

Nifty

[cretz]

The problem with moving logs from core to Python logging automatically is it requires polling, which is hard to guarantee in Python. Do I have a dedicated logging thread? Often not desirable. Or do I trust they will continually run the asyncio event loop given to me for the life of the logger? You might think that you're in a worker so it's ok, but lots of people are starting these asyncio loops just for one client call and terminating them.

Also there's of course the challenges with log ordering. I will have to research what TS does there and what kind of latency/backlog we'd tolerate to do stream sorting.

I have opened #407 to track it, but for some use cases from users, this PR unblocks them.

[cretz]

I may hold off on merging this. We may want a model where Rust pushes a notification once it has buffered logs to be drained based on temporalio/sdk-core#618.

[mjameswh]

Suggested change

	"""A buffer that can be set on :py:class:`LoggnigConfig` to record logs
	"""A buffer that can be set on :py:class:`LoggingConfig` to record logs

[cretz]

Ok, this is not going to work. The team wants (buffered) logs pushed to Python logging without this flexibility. Closing.