Pull Request Dashboard

[github-actions]

Note

Open PRs are grouped by deterministic routing over per-thread LLM classifications. CI, conflicts, and activity age are computed deterministically and are shown as facts, not used as standalone routing reasons.

Waiting on maintainer (approved)

PR	Author	CI	Conflicts	Activity
Do not attempt to enumerate or normalize entries from carrier	jack-berg	✅	✅	1d
Restore compliance between Composite Samplers code and specs	PeterF778	✅	✅	1d
Add Prometheus translation strategy support	zeitlinger	✅	✅	1d

Waiting on approvers

PR	Author	CI	Conflicts	Activity
Update azul/zulu-openjdk Docker tag to v26	app/renovate	❌	✅	?
Fix Groovy compatibility in OpenTelemetrySdkBuilder	ADITYA-CODE-SOURCE	✅	❌	3d
[DRAFT] Entity SDK prototype	jsuereth	✅	❌	4d
Update to opentelemetry-configuration v1.1.0	jack-berg	✅	❌	8d
profiles: improve JFR export example	jhalliday	✅	✅	24d
Make StandardComponentId constructor public	brunobat	✅	❌	227d
[DO NOT MERGE] JFR API usage	jhalliday	❌	✅	71d

Waiting on authors

PR	Author	CI	Conflicts	Activity
Fix W3CBaggagePropagator to allow empty baggage values per W3C spec	dahyvuun	✅	✅	2d
Enforce OTLP request size limits	ADITYA-CODE-SOURCE	❌	✅	2d
Avoid dropping metrics when forceFlush() races with the periodic export	mahitha-ada	✅	✅	2d
Use HTTP error bodies in HttpExporter warnings	ADITYA-CODE-SOURCE	✅	✅	1d
Fix Groovy OpenTelemetrySdk builder loading	ADITYA-CODE-SOURCE	✅	✅	25d
Merge colliding Prometheus label values	ADITYA-CODE-SOURCE	✅	❌	30d
Replace ArrayBlockingQueue with park/unpark for BatchSpanProcessor$Worker	Khepu	✅	✅	51d
Add JSON pretty-print to logging-otlp exporters	lucacavenaghi97	✅	❌	24d

Waiting on external

PR	Author	CI	Conflicts	Activity
Add fallback endpoint support for OTLP exporters	sridharsurvi1	❌	❌	58d
Add a ConfigProvider callback for runtime instrumentation option changes	jackshirazi	❌	❌	3d

Workflow failure tracking issues

Issue	Comments	Updated
Workflow failed: Sonatype Guide dependency audit (daily) (#33)	10	2026-06-13

Diagnostics

PR #8474
facts: approved=True conflicts=no days_since_last_activity=1
threads: author=0 reviewer=0 external=0 none=1 unclear=0
llm: PRRT_kwDOCkv3g86I8spV -> none (The only comment is an optional wording suggestion on a doc comment, and the same reviewer later approved, so no follow-up appears to be required.)
route: maintainer

PR #8473
facts: approved=False conflicts=no days_since_last_activity=None
threads: author=0 reviewer=0 external=0 none=0 unclear=0
route: approver

PR #8468
facts: approved=True conflicts=no days_since_last_activity=2
threads: author=1 reviewer=0 external=0 none=0 unclear=0
llm: PRRT_kwDOCkv3g86ImrO2 -> author (The approver is still requesting code changes: remove the `seenWhitespace` logic and update the test to accept empty baggage after whitespace-only values. This leaves the implementation back with the PR author.)
route: author

PR #8467
facts: approved=False conflicts=yes days_since_last_activity=3
threads: author=0 reviewer=1 external=0 none=0 unclear=0
llm: pr-conversation -> reviewer (The reviewer asked for motivation/context, and the author answered that it is related to #8198. That puts the thread back in the reviewer’s court to continue review or decide if the explanation is sufficient.)
route: approver

PR #8464
facts: approved=False conflicts=yes days_since_last_activity=4
threads: author=0 reviewer=0 external=0 none=0 unclear=0
route: approver

PR #8451
facts: approved=False conflicts=yes days_since_last_activity=8
threads: author=0 reviewer=1 external=0 none=1 unclear=0
llm: PRRT_kwDOCkv3g86Hblrk -> reviewer (The author has already responded that the issue was fixed, so the next step is for a reviewer to re-check the updated code or continue the review.)
llm: PRRT_kwDOCkv3g86HbmIQ -> none (The only comment is the author explaining an implementation choice; it doesn’t request a follow-up or ask a question, so no clear action is needed from anyone.)
route: approver

PR #8450
facts: approved=True conflicts=no days_since_last_activity=1
threads: author=0 reviewer=1 external=0 none=1 unclear=0
llm: PRRT_kwDOCkv3g86IoHpI -> none (An approver left a non-blocking wording suggestion, and the same approver approved afterward, so no follow-up action is needed on this thread.)
llm: pr-conversation -> reviewer (The latest comment is the author asking a reviewer whether an issue is required, so the next step is for the reviewer to जवाब/decide.)
route: maintainer

PR #8446
facts: approved=False conflicts=no days_since_last_activity=2
threads: author=1 reviewer=0 external=0 none=0 unclear=0
llm: PRRT_kwDOCkv3g86Ikgwf -> author (The approver requested a code change: update the toString assertions to include the new limit field, so the PR author needs to implement that change.)
route: author

PR #8437
facts: approved=False conflicts=no days_since_last_activity=2
threads: author=1 reviewer=0 external=0 none=0 unclear=0
llm: pr-conversation -> author (The approver is questioning the PR’s approach and saying the forceFlush behavior change may not be needed, so the author needs to respond or revise the implementation.)
route: author

PR #8428
facts: approved=False conflicts=no days_since_last_activity=1
threads: author=2 reviewer=0 external=0 none=0 unclear=0
llm: PRRT_kwDOCkv3g86FNGwS -> author (An approver asked a direct question about the chosen number, so the author needs to explain or adjust it.)
llm: PRRT_kwDOCkv3g86JKWNr -> author (The approver is asking whether the test can be simplified, so the PR author needs to respond and, if appropriate, adjust the test.)
route: author

PR #8407
facts: approved=False conflicts=no days_since_last_activity=25
threads: author=1 reviewer=2 external=0 none=0 unclear=0
llm: PRRT_kwDOCkv3g86CMfQS -> reviewer (The reviewer requested justification comments, and the author replied that they added them in a follow-up commit, so the thread is back with the reviewer to re-check or acknowledge.)
llm: PRRT_kwDOCkv3g86CMnfF -> reviewer (The reviewer asked why the type changed to `Object`, and the author answered with the rationale. The next move is for the reviewer to confirm whether that explanation is acceptable.)
llm: pr-conversation -> author (The latest comment is a reviewer asking the author to consider `@CompileStatic` and questioning whether the reflective `IncubatingUtil` call is necessary, so the author needs to respond or adjust the implementation.)
route: author

PR #8364
facts: approved=False conflicts=yes days_since_last_activity=30
threads: author=2 reviewer=0 external=1 none=0 unclear=0
llm: PRRT_kwDOCkv3g86BhQsA -> author (The approver asked for code changes: add a clarifying comment and rework the test strategy to avoid unnecessary allocation by assuming no collision unless one occurs.)
llm: PRRT_kwDOCkv3g86BhVsZ -> author (The approver pointed out the fix only handles `attributes` and requested it also account for collisions from `resource`, `scope`, and `additionalAttributes`, so the author needs to update the implementation.)
llm: pr-conversation -> external (The author already said this PR is parked pending #8346, so the next step is blocked outside this thread/repository until that dependency settles.)
route: author

PR #8349
facts: approved=False conflicts=no days_since_last_activity=24
threads: author=0 reviewer=0 external=0 none=0 unclear=0
route: approver

PR #8346
facts: approved=True conflicts=no days_since_last_activity=1
threads: author=0 reviewer=4 external=0 none=0 unclear=0
llm: PRRT_kwDOCkv3g85_EBPg -> reviewer (The reviewer raised a spec/behavior question, and the author responded by updating the code and tests; the thread is now back in reviewer court for a follow-up review.)
llm: PRRT_kwDOCkv3g85_EEnc -> reviewer (The author responded to the suggestion and later said they added explicit `escaping=` test cases, so the ball is back in the reviewer’s court to re-check the change.)
llm: PRRT_kwDOCkv3g85_EFiy -> reviewer (The author addressed the test coverage request by adding parameterized cases, so the thread is back in reviewer court for confirmation.)
llm: PRRT_kwDOCkv3g85_ypRk -> reviewer (The author says they applied the requested cleanup across the strategy helpers, so the thread is now waiting on the reviewer/approver to re-check and respond.)
route: maintainer

PR #8240
facts: approved=False conflicts=no days_since_last_activity=51
threads: author=1 reviewer=0 external=0 none=0 unclear=0
llm: pr-conversation -> author (The author’s last comment says they still need to investigate why the benchmark metrics are zero and will work on that before the requested before/after benchmark results can be added.)
route: author

PR #8197
facts: approved=False conflicts=yes days_since_last_activity=58
threads: author=0 reviewer=0 external=1 none=0 unclear=0
llm: pr-conversation -> external (The discussion is waiting on the separate OpenTelemetry spec issue (#4973), so the next step depends on outside-repository spec governance rather than another repo participant.)
route: external

PR #8164
facts: approved=False conflicts=yes days_since_last_activity=24
threads: author=1 reviewer=0 external=0 none=0 unclear=0
llm: PRRT_kwDOCkv3g85z-n0C -> author (A reviewer requested a code change to the config key naming, and the thread is still unresolved; the author needs to implement or address that suggestion.)
route: author

PR #8076
facts: approved=False conflicts=yes days_since_last_activity=3
threads: author=0 reviewer=0 external=1 none=0 unclear=0
llm: pr-conversation -> external (The reviewer says they can approve/merge once the corresponding spec is available, so the thread is blocked on an upstream spec change outside this PR.)
route: external

PR #7763
facts: approved=False conflicts=yes days_since_last_activity=227
threads: author=0 reviewer=1 external=0 none=0 unclear=0
llm: pr-conversation -> reviewer (The reviewer asked why the change was needed, and the author replied with their rationale. The thread is back in the reviewer’s court to evaluate that answer and decide whether to approve or request more changes.)
route: approver

PR #7741
facts: approved=False conflicts=no days_since_last_activity=71
threads: author=0 reviewer=0 external=0 none=1 unclear=0
llm: pr-conversation -> none (The reviewer answered the author’s question with implementation options, and the later link is just informational; no explicit follow-up is requested in the thread.)
route: approver

Generated 2026-06-13 18:36 UTC