feat: Switch batch exports logging to async

[tomasfarias]

Problem

Had good results with moving file writing to a thread in #24792. Inspired by that, I reviewed where we could have more blocking code, and that lead me to our logging (and also to #24804).

Structlog provides async methods that use a thread pool for logging. Our processor chain is not that complex that should be blocking for too long, but occasional timeouts tell us that we still have some blocking code. As little as it may be, Temporal workflows work best when nothing is blocking, so, let's also not block when logging. Our workflows are entirely bound by IO, so the extra computational overhead is not significant for our use case.

Changes

• Switch all batch export logging calls to async variants (prefixed with a).

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Does this work well for both Cloud and self-hosted?

How did you test this code?

Nothing really changed, functionality-wise. So, existing tests should cover this PR.

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ IntermittentUploadPartTimeoutError: An intermittent RequestTimeout was raised while attempting to upload part 1 posthog.temporal.batch_exports.s3_batch_export ... View Issue
• ‼️ EndpointConnectionError: Could not connect to the endpoint URL: "https://1b-production-third-party-export.s3.us-west-2.ama... posthog.temporal.batch_exports.s3_batch_export ... View Issue

_{Did you find this useful? React with a 👍 or 👎}