[SVLS-8582] feat(logs): change default of durable log buffer size from 0 to 5

[lym953]

Background

DD_LAMBDA_DURABLE_FUNCTION_LOG_BUFFER_SIZE means how many logs (in terms of number of invocations) the extension buffers to wait for enrichment. If it's N (which is 5 right now), then the extension holds all logs for up to N invocations, waits for traces for these invocations to be sent from the tracer, then uses the metadata from the traces to enrich the logs.

If the function is not a durable function, then the extension holds all logs (for up to N invocations) at cold start. Then, as soon as it receives the platform.InitStart event and learns that the function is not a durable function, it releases all held logs and no longer holds logs.

Ideally, its default value should be a non-zero value, so the behavior is correct for both durable functions and non-durable functions, i.e.:

• logs for durable functions are held, and
• logs for non-durable functions are not held.

Actually, the default was 5 at the beginning. However, when the log holding logic was released, tracer-side changes that adds the necessary metadata to traces had not been released. As a result, the extension never gets the metadata it's waiting for, and some logs are somehow dropped. Therefore, #1239 changes the default back to 0 as a temporary mitigation of this issue.

Now, all the tracer-side changes (datadog-lambda-js, datadog-lambda-python) have been released, so we can change the default back to 5. The dropped-logs problem won't happen as long as the user uses the latest version for the tracer.

Overview

Changes the default of lambda_durable_function_log_buffer_size
(DD_LAMBDA_DURABLE_FUNCTION_LOG_BUFFER_SIZE) from 0 to 5, so instrumenting a durable
function no longer requires setting this env var to get logs enriched with durable execution
context.

Testing

• cargo test --lib — 541 passed, 0 failed
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --check — clean

No manual test on a live durable function yet.

Existing integration tests

Non-durable functions — covered. These suites ensures logs for non-durable functions are flushed correctly:

• integration-tests/tests/on-demand.test.ts — node/python/java/dotnet, 2 invocations each;
  asserts the Hello world! log is retrievable by request ID for both the cold and warm
  invocation.
• integration-tests/tests/lmi.test.ts — Managed Instance mode; asserts logs exist and that
  the Hello world! log is present.
• integration-tests/tests/auth.test.ts — asserts logs.length > 0 under delegated auth.

Durable functions — not covered. However, we have done lots of manual tests using DD_LAMBDA_DURABLE_FUNCTION_LOG_BUFFER_SIZE == 5 and ensured this works well for durable functions.

Next steps:

Update onboarding doc saying if extension v100+ is used, then the user doesn't need to set DD_LAMBDA_DURABLE_FUNCTION_LOG_BUFFER_SIZE to 5 since it's 5 by default.

🤖 Partially generated with Claude Code

[datadog-official]

⚠️ Warnings

🚦 1 Pipeline job failed

DataDog/datadog-lambda-extension | e2e-test-status (amd64)     

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0fd7aa9 | Docs | Datadog PR Page | Give us feedback!}

[Copilot]

Pull request overview

Updates Bottlecap’s Lambda configuration to restore the non-zero default for durable-function log buffering (DD_LAMBDA_DURABLE_FUNCTION_LOG_BUFFER_SIZE), so logs can be held briefly to await durable execution context and be enriched when tracer metadata arrives.

Changes:

• Change LambdaConfig default lambda_durable_function_log_buffer_size from 0 to 5.
• Update inline documentation for the config field and the env-var-backed source field to reflect the new default and behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.