Skip scheduling a redundant timeout task for synchronously-completed metric exports - #2
Draft
jaipilot[bot] wants to merge 1 commit into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Behavior lock
Ran the existing
PeriodicMetricReaderTestsuite (25 tests covering the newsetExporterTimeoutbuilder API, default 30s timeout, explicit timeout with/without batching, and slow-exporter timeout enforcement) against the unmodified PR head — all passed. This was recorded as the behavior baseline; the same command was re-run against the final candidate and still passes, proving no observable behavior changed.Change
PeriodicMetricReader.Scheduled.applyTimeout()unconditionally scheduled a timer task viascheduler.schedule(...)and registered awhenCompletecallback to cancel it. BecauseCompletableResultCode.whenComplete()runs its callback synchronously when the target result is already done, every synchronously-completed export (in-memory/logging exporters, or exporters that already return a cachedofSuccess()/ofFailure()) paid the cost of scheduling a timer and immediately cancelling it, once per export call (and once per batch when batching is enabled).Added a fast path: when the export result is already done, return
CompletableResultCode.ofSuccess()/ofFailure()directly — the exact sameisSuccess()/isDone()/getFailureThrowable()(always null) that the prior scheduled-then-cancelled path produced. The asynchronous/slow-exporter timeout path is untouched.Proof
Added
applyTimeout_skipsSchedulingForSynchronouslyCompletedExport, a deterministic operation-count test using the repository's existing mocked-ScheduledExecutorServicepattern (seestartOnlyOnce). It assertsscheduler.schedule(...)is never invoked when the exporter completes synchronously. Verified this test fails against the original PR-head implementation (MockitoNeverWantedButInvoked, 1 actual invocation) and passes against the candidate (0 invocations) — a real, evidence-backed elimination of wasted work, not a timing guess.Verification
./gradlew :sdk:metrics:test --tests "io.opentelemetry.sdk.metrics.export.PeriodicMetricReaderTest"— passed before and after../gradlew :sdk:metrics:check— passed (tests, spotless, checkstyle, jApiCmp). No public API diff.Scope notes
Cleanup and modernization passes were evaluated and found no additional safe, in-scope improvement: no dead code, no build/version files were touched by the original PR, and the changed code requires no dependency upgrade. This mirror does not claim the original upstream work and is not intended to be merged or opened against the upstream repository.
Generated by JAIPilot Cloud for #1 from Anthropic session
sesn_01VgrUCPurgr22AcgEM7hJXK.