[pcbeingused333]

Fixes #877

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Issue Link, if available

#877

Description

Exporting a long execution re-serialized the whole telemetry record once per operation. truncateRecord calls truncate with bounded = false, and Meter.fits then measures the record before every step. DurableExecutionTelemetry.exportRecord used that path for every exporter except LambdaLogExporter, which already calls truncateMeasured (bounded = true). With CloudWatchLogsExporter's limit (256,000 bytes) and by-name rendering, a record of 2,000 simple steps measured the record thousands of times. The same path is what #877 timed at about 15 s for 4,000 steps.

Built-in exporters now use the bounded meter. The shrink bound covers two copies of each operation, so OperationsFormat.BOTH (the operations array and the by-name map) and the OTel body, which embeds that JSON once as a string, drop the same operations as checking after every step. LambdaLogExporter is unchanged and still measures its line with one copy. A custom render is not in the built-in package and still checks after every drop.

Demo/Screenshots

N/A

Design

• Design note (rule 3): not needed (bug fix, no public API change). The approach is the one in [Bug]: telemetry truncation time grows with the square of the operation count for size-limited exporters other than LambdaLogExporter #877.
• Simpler options considered (rule 2): special-casing only CloudWatchLogsExporter leaves the other size-limited exporters on the slow path. Turning bounded on inside truncateRecord would also bound custom renders, which [Bug]: telemetry truncation time grows with the square of the operation count for size-limited exporters other than LambdaLogExporter #877 says must keep exact checks. A binary search over the drop count, as in the Go SDK, can drop operations the linear pass keeps when removing a small result makes the record larger. The bounded meter already in this module skips only checks that cannot succeed.
• Root cause (rule 5): truncateRecord passes bounded = false, and exportRecord used it for every exporter other than LambdaLogExporter.
• Net change: +31 lines in two production files (+47/−16); 0 public API members added or removed.

Assumptions

None. The size checks measure this module's own JSON (Json.byteSize of render, or LambdaLogExporter.renderedSize). No assumption about CloudWatch, OTel, or any other service.

Decisions not covered by the issue or the design note

• A built-in exporter is recognized by its package (software.amazon.lambda.durable.telemetry.exporters), not by a new method on TelemetryExporter. Adding that method would change the public API. A custom class in some other package keeps exact checks.
• Every built-in JSON rendering uses a shrink bound of two copies, rather than a branch per OperationsFormat. Array and by-name renderings only need one copy; the extra copy measures a bit more often and drops the same operations. BOTH needs two: with one copy the pass dropped 27 operations where the exact pass dropped 18.
• No separate skip was added for operations that have no result. Once a measurement is still over the limit and nothing has been dropped, the bounded meter already skips the later checks in that step. Custom renders still measure every step.

Checklist

• I have filled out every section of the PR template
• I have thoroughly tested this change
• Every new branch has a test that fails without it (rule 4)
• For a bug fix: the description or commit order shows the regression test failing before the fix and passing after it (rule 5)
• Every edited test expectation is listed in the description, with the reason (rule 5)

Testing

Unit Tests

Yes. TruncationCostTest fails on the unchanged code: cloudWatchByNameShapeMeasuresAFewTimesAndKeepsTheExactOperations reports 2433 measurements for 2000 operations (the limit in the test is 100). bothFormatAndOtelBodyMatchTheExactPass passes on the unchanged code because the exact pass is the reference; it guards the two-copy bound (see below). After the fix all three tests pass, the kept operations match truncateRecord, and a custom render still measures more than once per operation.

mvn -pl telemetry-exporter -am test -Dtest=TruncationCostTest,LambdaLogLineSizeTest,TruncationTest -Dsurefire.failIfNoSpecifiedTests=false -Djacoco.skip=true in maven:3.9-eclipse-temurin-21: 13 tests, 0 failures. The same command without -Dtest, still in that image, runs the telemetry-exporter module: 251 tests, 0 failures. No existing test expectation was edited. With the shrink bound forced to one copy, bothFormatAndOtelBodyMatchTheExactPass fails (droppedOperations 27 vs 18).

Integration Tests

No. Truncation runs in memory before any exporter sends.

Examples

Not applicable.

---

This change was prepared with the assistance of an AI coding tool (Claude) and submitted by the account owner.