Record error.type on failed collections in PeriodicMetricReader#8650
Open
TimurRakhmatullin86 wants to merge 1 commit into
Open
Conversation
The self-observability sample for otel.sdk.metric_reader.collection.duration was always recorded with a null error: the local `error` variable was declared but never assigned, so a failed collectAllMetrics() was reported as a successful collection (error.type never set) - hiding exactly the failures an operator watches this signal for. Set `error` to the throwable's class name before it propagates, mirroring BatchSpanProcessor.exportCurrentBatch(), so the finally records the failure. Signed-off-by: Timur Rakhmatullin <174210871+TimurRakhmatullin86@users.noreply.github.com>
Pull request dashboard statusStatus last refreshed: 2026-07-21 21:49:28 UTC.
This automated status or its linked feedback items may be incorrect. If something looks wrong, report it with the result you expected. |
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.
Problem
In
PeriodicMetricReader.Scheduled.doRun()the self-observability sample forotel.sdk.metric_reader.collection.durationis always recorded with anullerror:erroris declared, initialized tonull, and never assigned anywhere in the method, soMetricReaderInstrumentation.recordCollection'sif (error != null)branch that attaches theerror.typeattribute is unreachable from this caller. WhencollectAllMetrics()throws, thefinallystill records the sample — as a successful collection with noerror.type— andthe exception propagates to the outer
catch (Throwable). The self-observability histogramtherefore reports error-free collections while the reader is exporting nothing, which is
exactly the signal an operator would use to detect the outage.
The sibling
BatchSpanProcessor.exportCurrentBatch()uses the sameString error = null; … finally { instrumentation…(…, error); }shape but assignserroron each failure path.Fix
Set
errorto the throwable's class name before it propagates:The rethrow keeps the existing control flow — the exception still reaches the same outer
catch (Throwable)— so the only change is that the recorded sample now carrieserror.type.(
ThrowableUtil.propagateIfFatalis intentionally not added: the outer catch already handlesall throwables, so it would be a no-op here.)
Tests
SdkMeterProviderMetricsTest.collectionFailureIsRecordedWithErrorType: registers aMetricProducerthat throws on the firstproduce()then succeeds, flushes twice, and assertsthe exported
otel.sdk.metric_reader.collection.durationpoint carrieserror.type = java.lang.IllegalStateException. It fails against the current code (the point hasno
error.type) and passes with the fix. Full:sdk:metrics:testsuite and:sdk:metrics:spotlessCheckpass; errorprone/NullAway clean.