[IzaakGough]

Fixes #172.

• Non-JSON values no longer crash the logger. Exceptions, exception classes, objects whose repr raises, and non-string dict keys are coerced to strings instead of raising TypeError. Both logger.error("...", error=e) and the documented sys.exc_info()[0] pattern now work.
• ERROR logs carry a top-level stack_trace. It comes from an exception passed to the logger, or from the exception currently being handled when none is passed. The JS SDK puts the trace in message, but Error Reporting checks stack_trace first, so Python uses the dedicated field.
• A passed exception never gets another exception's trace. If it has no traceback (it was never raised), no stack_trace is added rather than falling back to the active exception.

Covered by unit tests, and verified on a deployed Python 3.13 function: errors logged with a passed or active exception show up in Error Reporting, and a never-raised exception adds no trace.

[gemini-code-assist]

Code Review

This pull request introduces exception logging capabilities to the logger, including a new exception function to log active stack traces and utility functions to safely serialize exceptions and handle circular references in exception arguments. Comprehensive tests have been added to verify these changes. The review feedback suggests improving type safety by changing the type of the refs parameter from set[_typing.Any] to set[int] in both _exception_from_args and _remove_circular, as it is used to track object IDs.

[cabljac]

My main concern here is divergence from what JS does. I think JS puts the stack trace into the message field. It has no separate field or exception dict equivalent. Generally we need to keep the SDKs aligned

Can we check if exceptions logged via this new approach show up in the error reporting console?

[cabljac]

Dug into the Error Reporting docs: jsonPayload is evaluated stack_trace -> exception -> message, so the dedicated field is the highest-priority path and traceback.format_exception gives the format it parses. So I'm now happy with the dedicated field and don't think we need to align with JS further.

Could we add a code comment where we set stack_trace noting why we diverge from JS (it puts the trace in message; we use the dedicated field because Error Reporting checks it first)? Just so nobody realigns it later and regresses it.

[IzaakGough]

@cabljac I deployed this branch to a test project (Python 3.13, 2nd gen) to check Error Reporting:

• logger.error("...", error=e) inside except: entry has a top-level stack_trace and appears in Error Reporting.
• logger.error("...") inside except with nothing passed: same, grouped with the case above since both raise from the same place.
• An exception that was never raised, logged while handling a different one: no stack_trace, and nothing in Error Reporting.

All three arrived as jsonPayload at ERROR severity, so the dedicated field works as the docs describe.