[litianningdatadog]

What does this PR do?

flush() now compresses its batches first (only if some endpoint uses compression), then awaits the API key resolver, then sends. Same requests and bytes; each batch is still compressed at most once.

Motivation

Part of SVLS-8713: bottlecap (the Datadog Lambda Extension) is replacing its own logs aggregator and flusher with this crate. Two rules for the whole stack:

• Nothing changes for existing users of this crate (for example serverless-compat): every new behavior is opt-in, defaults and public API stay the same (additions only), no new environment variables, no new dependencies.
• Nothing changes for Lambda users: the options let bottlecap reproduce its current behavior exactly.

Found by a real Lambda A/B test of bottlecap with this stack vs main: the first flush after a cold start was about 20 ms (11–13%) slower. That flush waits for the first API key lookup (a Secrets Manager call, 70–110 ms), and the shared flusher compressed only after it, while bottlecap's old flusher compressed first so the work overlapped. With compression disabled on both sides the gap disappeared, confirming the cause. Warm flushes weren't affected (the key is cached).

Additional Notes

After this change the same Lambda test showed parity: first-flush time −3.9% [95% CI −7.8%, +2.7%] over 40 cold starts, and warm, 128 MB, high-volume, all flush strategies and failing-intake runs all within noise vs main and vs the v101 release. A #[cfg(test)] thread-local counter in compress_zstd lets the tests check the ordering deterministically (no cost in release builds).

Describe how to test/QA your changes

114 tests pass (new: every batch compressed before the key is requested and not again; extras-only compression; nothing compressed when no endpoint wants it; each mutation-checked). Workspace clippy, FIPS clippy and cargo check -p datadog-serverless-compat clean.

Stack

Each PR is nested under the PR it builds on (and targets). Review and merge from the top down.

serverless-components (datadog-logs-agent options; merge first)

• main
  • [SVLS-8713] test(logs-agent): pin current default behavior with characterization tests #189 characterization tests (pin today's defaults)
    • [SVLS-8713] build(logs-agent): let users choose the FIPS TLS backend #190 default / fips features
      • [SVLS-8713] feat(logs-agent): accept pre-serialized logs and an oversize policy #191 pre-serialized logs + oversize policy
        • [SVLS-8713] feat(logs-agent): optional API key resolver and Datadog intake URL override #192 API key resolver + intake URL override
          • [SVLS-8713] feat(logs-agent): add a retry-only method and an optional flush policy #193 retry() + FlushPolicy
            • [SVLS-8713] perf(logs-agent): compress each log batch only once #194 compress each batch once
              • 👉 [SVLS-8713] perf(logs-agent): compress log batches before waiting for the API key #195 compress before waiting for the API key ← this PR

datadog-lambda-extension (bottlecap)

• main
  • [SVLS-8713] test(logs): contract tests, fake logs intake and benchmark for the logs pipeline datadog-lambda-extension#1448 contract tests, fake intake, benchmark
    • [SVLS-8713] fix(logs): send additional endpoints the Datadog intake format when OPW is on datadog-lambda-extension#1449 fix: OPW applies only to the primary endpoint
      • [SVLS-8713] fix(logs): drop a log too large for any payload instead of blocking the queue datadog-lambda-extension#1450 fix: drop a log too large for any payload
        • [SVLS-8713] test(logs): pin that a reloaded API key is used on the next flush datadog-lambda-extension#1451 pin: reloaded API key is used
          • bc-1: use the shared aggregator (opens after the serverless-components PRs merge)
            • bc-2: use the shared flusher (opens after the serverless-components PRs merge)

🤖 Generated with Claude Code