`LogQueueListener` crashes when logging `RpcError`s

[dvschuyl]

Bug Description

When performing an RPC from my agent to my client and I purposely close the connection, a RpcError will be raised at the agent side. This is intended behaviour! However, the newly introduced agent-insights logger cannot handle such errors:

TypeError: RpcError.__init__() missing 1 required positional argument: 'message'

Expected Behavior

Either:

1. RpcError should be correctly pickled
2. or, ignore/drop this LogRecord such that the program does not crash

Reproduction Steps

import logging
from typing import override
import pickle
from livekit.rtc import RpcError

# This simulates the LogQueueListener receiving data
class LogHandler(logging.Handler):
    @override
    def emit(self, record: logging.LogRecord) -> None:
        # Data is send by some logging handler
        data = pickle.dumps(record)
        ...

        # The LogQueueListener will receive data and try to unpickle it
        pickle.loads(data)


# Setup
logging.getLogger().addHandler(LogHandler())

# This is fine...
logging.info("This is fine...")

# This is not fine...
logging.error(
    "This is crashes the program...",
    exc_info=RpcError(code=0, message="Test RPC error"),
)

This example will crash with the following error:

TypeError: RpcError.__init__() missing 1 required positional argument: 'message'

Operating System

Linux, macOS

Models Used

No response

Package Versions

livekit-agents==1.3.6

Session/Room/Call IDs

No response

Proposed Solution

# This is a temporary fix!

# Inside the `LogQueueListener`, update `_monitor` method to:

def _monitor(self) -> None:
    while True:
        try:
            data = self._duplex.recv_bytes()
        except utils.aio.duplex_unix.DuplexClosed:
            break

        try:
            record = pickle.loads(data)
            if isinstance(record, logging.LogRecord):
                self.handle(record)
        except Exception:
            pass

Additional Context

No response

Screenshots and Recordings

No response

[longcw]

this should be fixed in #4185

[longcw]

the fix was released in 1.3.7