diff --git a/.github/scripts/pull-request-dashboard/eval/regenerate_baseline.py b/.github/scripts/pull-request-dashboard/eval/regenerate_baseline.py new file mode 100644 index 00000000000..a1d5e6eed42 --- /dev/null +++ b/.github/scripts/pull-request-dashboard/eval/regenerate_baseline.py @@ -0,0 +1,246 @@ +"""Re-measure the recorded baseline in reviewer_feedback_cases.json. + +Drives from the cases already in the file rather than re-collecting them from +GitHub. Re-collecting would silently change the set, because the original +collection kept only pull requests that were open on the day it ran. + +Raw responses are cached in .cache/baseline/ beside the dashboard scripts, so a +failed or interrupted run resumes without paying for the calls it already made, +and a change to how answers are read costs nothing to apply. + +Run manually; it makes several hundred model calls. +""" + +from __future__ import annotations + +import argparse +import hashlib +import json +import sys +from collections import Counter +from concurrent.futures import ThreadPoolExecutor +from datetime import UTC, datetime +from pathlib import Path +from threading import Lock +from uuid import uuid4 + +sys.path.insert(0, str(Path(__file__).resolve().parent.parent)) + +import classification # noqa: E402 +from score_reviewer_feedback import CASES, batch_cases # noqa: E402 + +CACHE_DIR = Path(__file__).resolve().parent.parent / ".cache" / "baseline" +PROMPT = "REVIEWER_FEEDBACK_PROMPT_TEMPLATE" +# The shipped binary answers in the recorded labels themselves, so this maps one +# onto the other unchanged. It stays because the file records the mapping it was +# built with, and a prompt answering in its own vocabulary would need one. +ACTION_LABELS = {"author_action": "author_action", "no_author_action": "no_author_action"} + +_printed = Lock() + + +def batch_prompt(batch: list[dict]) -> str: + """The prompt the dashboard would send for one batch.""" + items = [ + { + "discussion_id": c["id"], + "requester": c["requester"], + "pr_author": c["pr_author"], + "body": c["body"], + } + for c in batch + ] + # The cases already hold the joined comment body the pipeline would build, + # so they are their own prompt input. Copies, because rendering truncates in + # place when a batch runs long. + return classification.render_top_level_batch_prompt( + items, + classification.REVIEWER_FEEDBACK_PROMPT_TEMPLATE, + [dict(item) for item in items], + ) + + +def cache_key(prompt: str, model: str, salt: str) -> str: + """Key on the prompt text itself, so a change to how it renders misses.""" + payload = json.dumps( + {"prompt": prompt, "model": model, "salt": salt}, sort_keys=True + ) + return hashlib.sha256(payload.encode("utf-8")).hexdigest()[:32] + + +def run_batch(batch: list[dict], model: str, salt: str) -> dict: + """Return the raw Copilot result for one batch, from cache when present.""" + prompt = batch_prompt(batch) + path = CACHE_DIR / f"{cache_key(prompt, model, salt)}.json" + if path.exists(): + return json.loads(path.read_text(encoding="utf-8")) + + try: + proc = classification.run_copilot(prompt, model) + raw = {"returncode": proc.returncode, "stdout": proc.stdout} + except Exception as e: # noqa: BLE001 - one bad batch must not end the run + raw = {"returncode": -1, "stdout": "", "error": f"{type(e).__name__}: {e}"} + # A failure is not a result: caching it would make every later run replay it + # instead of retrying the call. Via a temporary name, so an interrupt cannot + # leave a half-written entry for the next run to read back. + if raw["returncode"] == 0: + tmp = path.with_name(f"{path.name}.{uuid4().hex}.tmp") + tmp.write_text(json.dumps(raw), encoding="utf-8") + tmp.replace(path) + return raw + + +def answers(raw: dict, batch: list[dict]) -> dict[str, str]: + """Verdicts keyed by case id, keeping only ids that were asked for. + + A repeated id is dropped rather than resolved, matching production, which + fails a discussion whose id came back more than once. + """ + if raw.get("returncode") != 0: + return {} + parsed = classification.extract_json_object(raw.get("stdout") or "") or {} + items = parsed.get("items") + if not isinstance(items, list): + return {} + requested = {c["id"] for c in batch} + out: dict[str, str] = {} + seen: set[str] = set() + for entry in items: + if not isinstance(entry, dict): + continue + case_id = entry.get("discussion_id") + if not isinstance(case_id, str) or case_id not in requested: + continue + if case_id in seen: + out.pop(case_id, None) + continue + seen.add(case_id) + verdict = str(entry.get("verdict") or "").strip().lower() + if verdict in ACTION_LABELS: + out[case_id] = verdict + return out + + +def measure(cases: list[dict], model: str, runs: int, workers: int) -> list[dict[str, str]]: + CACHE_DIR.mkdir(parents=True, exist_ok=True) + batches = batch_cases(cases) + # A separate salt per run keeps the cache from replaying one trial as all of + # them, which would report perfect stability no matter how the model behaves. + tasks = [(batch, f"baseline-{n}") for n in range(runs) for batch in batches] + print(f"{len(batches)} batches x {runs} runs = {len(tasks)} calls", flush=True) + done = 0 + + def work(task: tuple[list[dict], str]) -> tuple[str, dict[str, str]]: + nonlocal done + batch, salt = task + result = answers(run_batch(batch, model, salt), batch) + with _printed: + done += 1 + if done % 20 == 0 or done == len(tasks): + print(f" {done}/{len(tasks)}", flush=True) + return salt, result + + with ThreadPoolExecutor(max_workers=workers) as pool: + results = list(pool.map(work, tasks)) + + trials: list[dict[str, str]] = [{} for _ in range(runs)] + for salt, result in results: + trials[int(salt.rsplit("-", 1)[1])].update(result) + return trials + + +def rebuild(payload: dict, trials: list[dict[str, str]], model: str) -> dict: + cases = [] + for case in payload["cases"]: + raw = [trial.get(case["id"]) for trial in trials] + observed = [ACTION_LABELS[a] for a in raw if a is not None] + # An unanswered run is not an observation; a substitute label would make + # the file claim evidence it does not have. + if any(a is None for a in raw): + role, stability, recorded = "context", None, None + elif len(set(observed)) == 1: + role, stability, recorded = "scored", "stable", observed[0] + else: + role, stability, recorded = "scored", "flaky", None + cases.append({ + **{k: case[k] for k in + ("id", "repo", "pull_request", "requester", "pr_author", "review_state", + "root_timestamp", "body")}, + "role": role, + "stability": stability, + "recorded_label": recorded, + "adjudicated_label": case["adjudicated_label"], + "run_actions": raw, + "run_labels": observed, + }) + # The order the dashboard sends a pull request's items in, which decides + # where the ten-item batch boundaries fall and so what each prompt contains. + cases.sort(key=lambda c: (c["repo"], c["pull_request"], c["root_timestamp"])) + roles = Counter(c["role"] for c in cases) + stabilities = Counter(c["stability"] for c in cases) + return { + **payload, + "generated_at": datetime.now(UTC).strftime("%Y-%m-%d"), + "baseline_configuration": { + **payload["baseline_configuration"], + "model": model, + "prompt": PROMPT, + "runs": len(trials), + }, + "action_labels": ACTION_LABELS, + "counts": { + "cases": len(cases), + "scored": roles["scored"], + "context": roles["context"], + "stable": stabilities["stable"], + "flaky": stabilities["flaky"], + "adjudicated": sum(1 for c in cases if c["adjudicated_label"]), + }, + "cases": cases, + } + + +def main() -> None: + parser = argparse.ArgumentParser(description=__doc__) + parser.add_argument("--model", default="gpt-5.4-mini") + parser.add_argument("--runs", type=int, default=5) + parser.add_argument("--workers", type=int, default=12) + parser.add_argument("--dry-run", action="store_true", help="report without writing") + args = parser.parse_args() + # Zero runs would observe nothing and rewrite every case as flaky. + if args.runs < 1: + parser.error("--runs must be at least 1") + if args.workers < 1: + parser.error("--workers must be at least 1") + + payload = json.loads(CASES.read_text(encoding="utf-8")) + before = payload["counts"] + trials = measure(payload["cases"], args.model, args.runs, args.workers) + rebuilt = rebuild(payload, trials, args.model) + after = rebuilt["counts"] + + print(f"\n {'was':>6} {'now':>6}") + for key in ("cases", "scored", "context", "stable", "flaky", "adjudicated"): + print(f"{key:<11} {before.get(key, 0):>6} {after[key]:>6}") + + by_id = {c["id"]: c for c in payload["cases"]} + changed = [ + c for c in rebuilt["cases"] + if c["stability"] == "stable" == by_id[c["id"]]["stability"] + and c["recorded_label"] != by_id[c["id"]]["recorded_label"] + ] + print(f"\nlabel changed on {len(changed)} cases stable in both recordings") + print( + "label balance " + f"{dict(Counter(c['recorded_label'] for c in rebuilt['cases'] if c['recorded_label']))}" + ) + + if args.dry_run: + print("\ndry run; nothing written") + return + CASES.write_text(json.dumps(rebuilt, indent=2, ensure_ascii=False) + "\n", encoding="utf-8") + print(f"\nwritten to {CASES}") + + +if __name__ == "__main__": + main() diff --git a/.github/scripts/pull-request-dashboard/eval/reviewer_feedback_cases.json b/.github/scripts/pull-request-dashboard/eval/reviewer_feedback_cases.json index 4e91a0575a7..e546792110d 100644 --- a/.github/scripts/pull-request-dashboard/eval/reviewer_feedback_cases.json +++ b/.github/scripts/pull-request-dashboard/eval/reviewer_feedback_cases.json @@ -1,10 +1,9 @@ { "note": "`recorded_label` is how the shipped classifier behaved when this file was generated, not an adjudicated correct answer. A run matching it has not regressed; it has not been shown to be right. Set `adjudicated_label` on a case once a human has decided it.", - "generated_at": "2026-07-29", + "generated_at": "2026-08-01", "baseline_configuration": { "model": "gpt-5.4-mini", - "prompt": "TOP_LEVEL_REVIEWER_FEEDBACK_BATCH_PROMPT_TEMPLATE", - "prompt_note": "retired; removed once it was no longer the shipped classifier, so this baseline can no longer be reproduced", + "prompt": "REVIEWER_FEEDBACK_PROMPT_TEMPLATE", "runs": 5, "batching": "one pull request per batch, as the dashboard classifies", "note": "one configuration, the one in production. Other models and prompt shapes are what this set is for, so none took part in labelling it. Cases the classifier left unanswered in any run were excluded rather than given a substitute label." @@ -14,9 +13,8 @@ "no_author_action": "the item needs nothing from the pull request author" }, "action_labels": { - "author": "author_action", - "unclear": "author_action", - "none": "no_author_action" + "author_action": "author_action", + "no_author_action": "no_author_action" }, "fields": { "role": "scored cases carry the metrics; context cases are ones the classifier left unanswered in at least one run, so nothing was recorded for them and they are present only so batches match the ones the baseline was measured in", @@ -24,15 +22,16 @@ "run_actions": "the classifier's raw answer in each run, null when it did not answer", "run_labels": "the answers it did give, mapped through action_labels", "recorded_label": "the label the baseline settled on, null when it did not settle", - "adjudicated_label": "the label a human decided, null until one has" + "adjudicated_label": "the label a human decided, null until one has", + "root_timestamp": "the timestamp the dashboard orders a pull request's items by; cases are stored and measured in that order, so batches match the ones it sends" }, "counts": { - "cases": 611, - "scored": 594, - "context": 17, - "stable": 531, - "flaky": 63, - "adjudicated": 0 + "cases": 616, + "scored": 613, + "context": 3, + "stable": 529, + "flaky": 84, + "adjudicated": 1 }, "cases": [ { @@ -42,17 +41,18 @@ "requester": "andrzej-stencel", "pr_author": "Nitesh-vaidyanath", "review_state": null, + "root_timestamp": "2026-03-04T12:14:08Z", "body": "Sorry I wasn't able to get to this due to lack of bandwidth. Anybody else want to review this?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -69,24 +69,25 @@ "requester": "meldegwi", "pr_author": "alexcams", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-04-12T15:31:02Z", "body": "Hi @alexcams, thanks for working on this. I've left some suggestions for your consideration, please take them (with a grain of salt) as improving ideas and me thinking out loud :)", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -96,17 +97,18 @@ "requester": "meldegwi", "pr_author": "alexcams", "review_state": "COMMENTED", + "root_timestamp": "2026-04-14T07:18:32Z", "body": "That's pretty much what on my head. Thanks for making those changes, Alex.\n\nWould you mind to post the benchmarks result as well? It'd be helpful to track the performance cost of this new feature.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -123,20 +125,21 @@ "requester": "meldegwi", "pr_author": "alexcams", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-04-17T12:45:43Z", "body": "The benchmarks looks good, thanks for posting them, Alex. We almost there, just small nits for better readability, otherwise looks good to me :)", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "author_action", + "no_author_action", "author_action", "author_action", "author_action", @@ -150,17 +153,18 @@ "requester": "meldegwi", "pr_author": "alexcams", "review_state": "APPROVED", + "root_timestamp": "2026-04-20T10:01:46Z", "body": "LGTM. I'm not official approver though, so let's see what code owners think.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -177,21 +181,50 @@ "requester": "paulojmdias", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-02-11T20:45:07Z", "body": "Collector is already with go 1.25, you could move forward with this 🙏", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-3791368940", + "repo": "opentelemetry-collector-contrib", + "pull_request": 45773, + "requester": "ArthurSens", + "pr_author": "aknuds1", + "review_state": "COMMENTED", + "root_timestamp": "2026-02-12T14:33:42Z", + "body": "Looks like the commit used is forcing us to move to 1.25.5 🥲", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", "author_action", "author_action", "author_action" @@ -204,24 +237,25 @@ "requester": "ArthurSens", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-02-25T18:09:33Z", "body": "Just an update here. We discussed this PR in [slack](https://cloud-native.slack.com/archives/C07CCCMRXBK/p1771958044638699), and our first option is hope that consul maintainers are happy to downgrade their minimum Go version: https://github.com/hashicorp/consul/pull/23268\r\n\r\nIf we don't hear back from them in a week, we'll have to consider other options", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "author", - "none", - "none" + "author_action", + "author_action", + "no_author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", + "author_action", "author_action", "no_author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -231,17 +265,18 @@ "requester": "ArthurSens", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-03-03T20:03:32Z", "body": "Status update, https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/46609 was opened", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -258,17 +293,18 @@ "requester": "ArthurSens", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-04-02T23:01:44Z", "body": "I've opened https://github.com/open-telemetry/opentelemetry-collector/pull/15052, hopefully we can unblock this PR", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -285,20 +321,21 @@ "requester": "MovieStoreGuy", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-05-11T08:20:32Z", "body": "@ArthurSens , is it worth moving this PR to draft until we can resolve the associated issue?", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "no_author_action", + "author_action", "no_author_action", "no_author_action", "no_author_action", @@ -312,17 +349,18 @@ "requester": "ArthurSens", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-07-07T20:53:19Z", "body": "https://github.com/open-telemetry/opentelemetry-collector/pull/15052 got merged! @aknuds1, could you rebase the PR?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -339,17 +377,18 @@ "requester": "MovieStoreGuy", "pr_author": "aknuds1", "review_state": null, + "root_timestamp": "2026-07-15T06:15:33Z", "body": "Sorry, one more rebase for good measure!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -360,23 +399,24 @@ ] }, { - "id": "pr-review-3791368940", + "id": "pr-issue-comment-4359405621", "repo": "opentelemetry-collector-contrib", - "pull_request": 45773, - "requester": "ArthurSens", - "pr_author": "aknuds1", - "review_state": "COMMENTED", - "body": "Looks like the commit used is forcing us to move to 1.25.5 🥲", + "pull_request": 46173, + "requester": "schmikei", + "pr_author": "sfozz", + "review_state": null, + "root_timestamp": "2026-05-01T13:07:20Z", + "body": "Not stale, will need a maintainer to take a look. Will see if I can get someone", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -387,23 +427,24 @@ ] }, { - "id": "pr-issue-comment-4359405621", + "id": "pr-review-4221154677", "repo": "opentelemetry-collector-contrib", "pull_request": 46173, "requester": "schmikei", "pr_author": "sfozz", - "review_state": null, - "body": "Not stale, will need a maintainer to take a look. Will see if I can get someone", + "review_state": "APPROVED", + "root_timestamp": "2026-05-04T15:03:20Z", + "body": "@paulojmdias As a codeowner, I think this looks good to me and I believe any conflicts were addressed", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -420,17 +461,18 @@ "requester": "paulojmdias", "pr_author": "sfozz", "review_state": null, + "root_timestamp": "2026-05-04T15:04:45Z", "body": "@atoulme Can you give another look please ?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -447,17 +489,18 @@ "requester": "singhvibhanshu", "pr_author": "sfozz", "review_state": null, + "root_timestamp": "2026-07-13T02:42:08Z", "body": "This needs one more approval from the approvers.\r\nCould someone from @open-telemetry/collector-contrib-approvers please take a look at it.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -467,6 +510,34 @@ "no_author_action" ] }, + { + "id": "pr-review-4681630386", + "repo": "opentelemetry-collector-contrib", + "pull_request": 46173, + "requester": "axw", + "pr_author": "sfozz", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-13T03:51:11Z", + "body": "This won't work for cross-account observability (linked accounts), right? I think we would need to extract the account ID from the log group ARN in that case.\n\nShould the `autodiscovery` case capture the log group ARN and extract the account ID from that? I believe the STS addition may still be needed for the `named` config case.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-4964161272", "repo": "opentelemetry-collector-contrib", @@ -474,17 +545,18 @@ "requester": "dyl10s", "pr_author": "sfozz", "review_state": null, + "root_timestamp": "2026-07-14T00:26:08Z", "body": "> This won't work for cross-account observability (linked accounts), right? I think we would need to extract the account ID from the log group ARN in that case.\r\n> \r\n> Should the `autodiscovery` case capture the log group ARN and extract the account ID from that? I believe the STS addition may still be needed for the `named` config case.\r\n\r\nCross account observability currently does not work and requires a fix, https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/48762 \r\n\r\nIt could be worth trying to get that over the line before implementing this one.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -495,23 +567,24 @@ ] }, { - "id": "pr-review-4221154677", + "id": "pr-review-4040801374", "repo": "opentelemetry-collector-contrib", - "pull_request": 46173, - "requester": "schmikei", - "pr_author": "sfozz", - "review_state": "APPROVED", - "body": "@paulojmdias As a codeowner, I think this looks good to me and I believe any conflicts were addressed", + "pull_request": 46315, + "requester": "MovieStoreGuy", + "pr_author": "vesari", + "review_state": "COMMENTED", + "root_timestamp": "2026-04-01T01:45:34Z", + "body": "I haven't reviewed this completely, but wanted to provide some initial feedback on what I have seen so far.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -522,23 +595,24 @@ ] }, { - "id": "pr-review-4681630386", + "id": "pr-review-4068665597", "repo": "opentelemetry-collector-contrib", - "pull_request": 46173, - "requester": "axw", - "pr_author": "sfozz", + "pull_request": 46315, + "requester": "ArthurSens", + "pr_author": "vesari", "review_state": "COMMENTED", - "body": "This won't work for cross-account observability (linked accounts), right? I think we would need to extract the account ID from the log group ARN in that case.\n\nShould the `autodiscovery` case capture the log group ARN and extract the account ID from that? I believe the STS addition may still be needed for the `named` config case.", + "root_timestamp": "2026-04-07T14:00:03Z", + "body": "Hello helloooo 👋 -- Awesome progress here!!\n\nJust to align expectations, this PR creates the package for Collector's internal telemetry validation, right? It doesn't fix #44905 yet because we still need to wire this library with our CI somehow.\n\nAm I also understanding things correctly that this package spins up a new Weaver container for each OTLP message we want to validate? How would this wiring work if we're to validate hundreds of components at the same time?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -555,17 +629,18 @@ "requester": "ArthurSens", "pr_author": "vesari", "review_state": null, + "root_timestamp": "2026-04-07T14:12:03Z", "body": "We're also missing a README file with the codeowners of the new package :)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -582,17 +657,18 @@ "requester": "jmacd", "pr_author": "vesari", "review_state": null, + "root_timestamp": "2026-04-07T22:09:49Z", "body": "Here is maybe an example @vesari thanks to @braydonk's https://gist.github.com/braydonk/7067f20dde350a2bf23ea208aa937d97\r\n\r\nhttps://github.com/jmacd/weaver/pull/1", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -603,23 +679,24 @@ ] }, { - "id": "pr-issue-comment-4913162432", + "id": "pr-review-4319481162", "repo": "opentelemetry-collector-contrib", "pull_request": 46315, - "requester": "ChrsMark", + "requester": "braydonk", "pr_author": "vesari", - "review_state": null, - "body": "This addition will be really valuable, thank's @vesari and @braydonk! I'm looking forward to this. \r\nCouple of generic comments from my side.\r\n\r\n> This works successfully with synthetic data, however, I haven't applied it to any real component just yet. A good first candidate should be agreed upon. What is also yet to be addressed is the stability enforcement. Work is in progress.\r\n\r\n`k8s_attributes` processor is targeting v1/stability through https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/49274. I believe this component would make it for a great candidate since it's already based on stable Semantic Conventions and we don't have any strict validation for the schema in place.\r\n\r\nWith https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/49545 we only explicitly set the stability level \"manually\" and refer to the SemConv docs, but there is no guardrail or actual automatic linking from the component back to the spec/semconv.\r\n\r\n> Tests for the semconvtest package itself. These are not component-level compliance tests (those would be added to the components actually using the package).\r\n\r\nWould that make sense to have a sample component tested ...[truncated]", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-19T14:18:23Z", + "body": "Because of the way we have to work with Weaver's /stop endpoint, the testing API ends up looking really awkward from my original design. I think we can simplify it.\n\nI'm thinking an external user should just call a public function from the package called semconvtest.Test. For metrics for example that function would look something like func TestMetrics(t *testing.T, metrics pmetric.Metrics, opts ...WeaverOption) (assuming weaver options were refactored to the functional option pattern I mentioned in the other comment).\n\nThis function will essentially do all of what's here - it'll start a weaver container with the supplied options, send the logs to it, call stop, parse the livecheck report, and return findings. It obscures all the weaver stuff that I previously had them calling as individual steps. All these steps are basically necessary to work, so instead we can abstract all these steps away from the user, so they only know they need to call semconvtest.Test with their pdata.\nAlso, if these functions accept a t directly, then it can find the violations and mark the test as succeeded or failed.\n\nThis can also help resolve the comments around storing context i ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -630,77 +707,24 @@ ] }, { - "id": "pr-review-4040801374", + "id": "pr-issue-comment-4913162432", "repo": "opentelemetry-collector-contrib", "pull_request": 46315, - "requester": "MovieStoreGuy", + "requester": "ChrsMark", "pr_author": "vesari", - "review_state": "COMMENTED", - "body": "I haven't reviewed this completely, but wanted to provide some initial feedback on what I have seen so far.", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" - ] - }, - { - "id": "pr-review-4068665597", - "repo": "opentelemetry-collector-contrib", - "pull_request": 46315, - "requester": "ArthurSens", - "pr_author": "vesari", - "review_state": "COMMENTED", - "body": "Hello helloooo 👋 -- Awesome progress here!!\n\nJust to align expectations, this PR creates the package for Collector's internal telemetry validation, right? It doesn't fix #44905 yet because we still need to wire this library with our CI somehow.\n\nAm I also understanding things correctly that this package spins up a new Weaver container for each OTLP message we want to validate? How would this wiring work if we're to validate hundreds of components at the same time?", + "review_state": null, + "root_timestamp": "2026-07-08T09:05:13Z", + "body": "This addition will be really valuable, thank's @vesari and @braydonk! I'm looking forward to this. \r\nCouple of generic comments from my side.\r\n\r\n> This works successfully with synthetic data, however, I haven't applied it to any real component just yet. A good first candidate should be agreed upon. What is also yet to be addressed is the stability enforcement. Work is in progress.\r\n\r\n`k8s_attributes` processor is targeting v1/stability through https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/49274. I believe this component would make it for a great candidate since it's already based on stable Semantic Conventions and we don't have any strict validation for the schema in place.\r\n\r\nWith https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/49545 we only explicitly set the stability level \"manually\" and refer to the SemConv docs, but there is no guardrail or actual automatic linking from the component back to the spec/semconv.\r\n\r\n> Tests for the semconvtest package itself. These are not component-level compliance tests (those would be added to the components actually using the package).\r\n\r\nWould that make sense to have a sample component tested ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4319481162", - "repo": "opentelemetry-collector-contrib", - "pull_request": 46315, - "requester": "braydonk", - "pr_author": "vesari", - "review_state": "COMMENTED", - "body": "Because of the way we have to work with Weaver's /stop endpoint, the testing API ends up looking really awkward from my original design. I think we can simplify it.\n\nI'm thinking an external user should just call a public function from the package called semconvtest.Test. For metrics for example that function would look something like func TestMetrics(t *testing.T, metrics pmetric.Metrics, opts ...WeaverOption) (assuming weaver options were refactored to the functional option pattern I mentioned in the other comment).\n\nThis function will essentially do all of what's here - it'll start a weaver container with the supplied options, send the logs to it, call stop, parse the livecheck report, and return findings. It obscures all the weaver stuff that I previously had them calling as individual steps. All these steps are basically necessary to work, so instead we can abstract all these steps away from the user, so they only know they need to call semconvtest.Test with their pdata.\nAlso, if these functions accept a t directly, then it can find the violations and mark the test as succeeded or failed.\n\nThis can also help resolve the comments around storing context i ...[truncated]", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -717,44 +741,18 @@ "requester": "braydonk", "pr_author": "vesari", "review_state": "COMMENTED", + "root_timestamp": "2026-07-11T13:27:05Z", "body": "Looks much better! I think this accomplishes what I had suggested last time, which is a simple API for receivers using this package of `Test` and pass a bunch of pdata. The Weaver stuff gets largely obscured from them, all they need to do is pass data and under the hood Weaver does the magic.\n\nI tried to think if it's worth trying to come up with a way to reuse the same `testcontainer` instance across all tests; currently each call to `Test` will result in the a new container being created, started, stopped, and shutdown within the call. \nI think this is probably fine, since as long as the same weaver tag is used for each test then I don't think it will pull a new container each time (I wonder if `latest` will work that way? worth a check).\n\nI left a couple small comments, but structurally I feel that this is in a good place!", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "none", - "none" - ], - "run_labels": [ - "author_action", + "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-issue-comment-4177357187", - "repo": "opentelemetry-collector-contrib", - "pull_request": 46506, - "requester": "edmocosta", - "pr_author": "Rajneesh180", - "review_state": null, - "body": "Thanks @Rajneesh180, sorry for the delay. I'll be back reviewing this one soon.", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ "no_author_action", @@ -771,17 +769,18 @@ "requester": "chatgpt-codex-connector", "pr_author": "Rajneesh180", "review_state": "COMMENTED", + "root_timestamp": "2026-02-28T05:07:11Z", "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `9fe03f420e`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](http://chatgpt.com/codex/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -798,17 +797,18 @@ "requester": "edmocosta", "pr_author": "Rajneesh180", "review_state": "COMMENTED", + "root_timestamp": "2026-03-04T17:58:56Z", "body": "Hi @Rajneesh180! Thank you for working on this! Before I can thoughtfully review it, let's try to avoid adding all this extra reflection code. We can probably leverage the existing `functions.buildArgs` for that, as it's already processing all that logic. I might be missing something, but I think we can check the functions argument there using the `ottl.isLiteralGetter()`, without having to go thought the parameters.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -825,17 +825,18 @@ "requester": "edmocosta", "pr_author": "Rajneesh180", "review_state": "COMMENTED", + "root_timestamp": "2026-03-13T13:05:25Z", "body": "Thanks for working on this @Rajneesh180, a few more ideas:\n - Considering almost all converters are deterministic, I think we could probably invert this logic, changing the non-deterministic ones to pass the new factory option.\n - Let's avoid the extra reflection. We can probably apply the same idea of the `functions.buildArgs` to drop the slice arg reflection part. Please also consider organizing the code a bit or adding some extra structs to improve readability, as retuning bare booleans for argument builders might be a bit confusing. \n - `ottl.WithIsDeterministic()` is exported, so I'd choose a name that describes this option a bit more, such as `ottl.NonDeterministicConverter()` or something like that. We should also validate this option allowing it to be used with converters only, not editors.\n - We probably don't need to export the `ottl.Factory.IsDeterministic()`. This interface is already \"private\" so not issues un-exporting this one as well, the less we export here, the better.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -845,6 +846,34 @@ "author_action" ] }, + { + "id": "pr-issue-comment-4177357187", + "repo": "opentelemetry-collector-contrib", + "pull_request": 46506, + "requester": "edmocosta", + "pr_author": "Rajneesh180", + "review_state": null, + "root_timestamp": "2026-04-02T12:12:19Z", + "body": "Thanks @Rajneesh180, sorry for the delay. I'll be back reviewing this one soon.", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, { "id": "pr-issue-comment-5022523681", "repo": "opentelemetry-collector-contrib", @@ -852,22 +881,23 @@ "requester": "anarwal", "pr_author": "paulojmdias", "review_state": null, + "root_timestamp": "2026-07-20T13:01:45Z", "body": "@paulojmdias I have a PR already for this https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/49466 - waiting on someone to review it.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", - "no_author_action", + "author_action", "no_author_action", "no_author_action" ] @@ -879,17 +909,18 @@ "requester": "anarwal", "pr_author": "paulojmdias", "review_state": null, + "root_timestamp": "2026-07-24T15:06:28Z", "body": "Thanks for the clarification @paulojmdias , I should have looked more closely :P \r\n\r\nI will update the table here https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/22095#issuecomment-4649650180 to reference your PR.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -906,24 +937,25 @@ "requester": "basti1302", "pr_author": "paulojmdias", "review_state": null, + "root_timestamp": "2026-03-31T11:03:35Z", "body": "I think it would be really good to have this, but apparently this has lost traction. Is there anything I can do to help to move it forward? I think it \"only\" lacks another round of reviews / an approval. :-)", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "none", - "author" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", "author_action", "no_author_action", - "author_action" + "no_author_action", + "no_author_action" ] }, { @@ -933,17 +965,18 @@ "requester": "dashpole", "pr_author": "paulojmdias", "review_state": null, + "root_timestamp": "2026-04-01T18:32:52Z", "body": "Sorry for the slow review. In some ways, i'm surprised this configuration is needed. I suspect the need stems from the fact that we aren't properly differentiating between cases where we aren't on the platform at all, and cases where we are on the platform, but the request fails.\r\n\r\nIf we aren't on the platform (e.g. the metadata endpoint returns a 404), we should never fail -- we should silently ignore. Any other errors should always fail. I guess the question is: Is there a use-case where someone wants a 404 to fail the resource detector?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -960,17 +993,18 @@ "requester": "basti1302", "pr_author": "paulojmdias", "review_state": null, + "root_timestamp": "2026-04-02T06:45:12Z", "body": "> I suspect the need stems from the fact that we aren't properly differentiating between cases where we aren't on the platform at all, and cases where we are on the platform, but the request fails.\r\n> If we aren't on the platform (e.g. the metadata endpoint returns a 404), we should never fail -- we should silently ignore. Any other errors should always fail.\r\n\r\nNot quite: My main interest (and the reason I raised #46579) is the situation (broadly speaking) where we actually are on the platform, but the platform is configured in a way so the resource detector cannot do its work. (Example: EKS detector, IMDS not enabled, permission DescribeInstances not present). Maybe the default should be to propagate the error and crash the collector, but there should also be an option to fail gracefully, e.g. stop the detector, but let the collector continue. The EC2 detector already has `fail_on_missing_metadata` and it works exactly like that, so there is precedent/prior art for this -- if the platform is EC2 but the permissions are not correct, the error is logged and the collector startup continues. \r\n\r\n> I guess the question is: Is there a use-case where someone wants a 404 to fail the reso ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -987,17 +1021,46 @@ "requester": "overmeulen", "pr_author": "Akash-Kumar-Sinha", "review_state": null, + "root_timestamp": "2026-05-07T09:20:25Z", "body": "Can we reopen this PR ? This fix is still expected", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4356731264", + "repo": "opentelemetry-collector-contrib", + "pull_request": 46947, + "requester": "paulojmdias", + "pr_author": "Akash-Kumar-Sinha", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-25T12:46:55Z", + "body": "PTAL into the Co-Pilot suggestions", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1014,17 +1077,18 @@ "requester": "paulojmdias", "pr_author": "Akash-Kumar-Sinha", "review_state": null, + "root_timestamp": "2026-06-03T10:09:43Z", "body": "@Akash-Kumar-Sinha, do you plan to review the suggestions before I can review them?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1041,17 +1105,18 @@ "requester": "Dainerx", "pr_author": "Akash-Kumar-Sinha", "review_state": null, + "root_timestamp": "2026-06-08T13:54:05Z", "body": "@Akash-Kumar-Sinha, any updates here? This fix is still needed.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1062,23 +1127,24 @@ ] }, { - "id": "pr-review-4356731264", + "id": "pr-review-4009954623", "repo": "opentelemetry-collector-contrib", - "pull_request": 46947, - "requester": "paulojmdias", - "pr_author": "Akash-Kumar-Sinha", + "pull_request": 47115, + "requester": "iblancasa", + "pr_author": "pathcl", "review_state": "COMMENTED", - "body": "PTAL into the Co-Pilot suggestions", + "root_timestamp": "2026-03-25T21:25:42Z", + "body": "I feel you are trying to solve 3 different issues:\n1. Create a ticket for each one\n2. Ensure to add a changelog in the PRs\n3. Provide regression tests for the issues you want to fix", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1095,17 +1161,18 @@ "requester": "iblancasa", "pr_author": "pathcl", "review_state": null, + "root_timestamp": "2026-04-23T08:30:27Z", "body": "> @iblancasa would you mind sharing which are the three issues? I only found 2 bugs\r\n\r\nSorry. I don't know why I wrote 3. There are 2.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1122,17 +1189,18 @@ "requester": "atoulme", "pr_author": "pathcl", "review_state": null, + "root_timestamp": "2026-04-23T15:06:02Z", "body": "Please also update to latest main and look at the checks CI.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1149,17 +1217,18 @@ "requester": "aarvee11", "pr_author": "pathcl", "review_state": null, + "root_timestamp": "2026-05-08T07:12:00Z", "body": "@pathcl Please ensure all the govulncheck tests pass. I have taken a look at the functionality upgrade and looks good for now. Lets quickly fix and move forward", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1176,44 +1245,18 @@ "requester": "singhvibhanshu", "pr_author": "pathcl", "review_state": null, + "root_timestamp": "2026-07-11T12:38:47Z", "body": "Kindly look at the lint CI failures.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4009954623", - "repo": "opentelemetry-collector-contrib", - "pull_request": 47115, - "requester": "iblancasa", - "pr_author": "pathcl", - "review_state": "COMMENTED", - "body": "I feel you are trying to solve 3 different issues:\n1. Create a ticket for each one\n2. Ensure to add a changelog in the PRs\n3. Provide regression tests for the issues you want to fix", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -1230,17 +1273,18 @@ "requester": "axw", "pr_author": "singhvibhanshu", "review_state": null, + "root_timestamp": "2026-06-03T01:46:01Z", "body": "This is fairly domain-specific, so will need to be reviewed by code owners.\r\n\r\n@schmikei @ishleenk17 PTAL", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1257,17 +1301,18 @@ "requester": "paulojmdias", "pr_author": "Dylan-M", "review_state": null, + "root_timestamp": "2026-04-07T18:43:31Z", "body": "I have not looked into the code already but this this should have a changelog entry", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1284,17 +1329,18 @@ "requester": "braydonk", "pr_author": "Dylan-M", "review_state": "COMMENTED", + "root_timestamp": "2026-04-09T13:21:41Z", "body": "The PR LGTM, I'd like to first figure out whether the answer is instead to just [not default `top_n` to 1 at all](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/47444#issuecomment-4214505183) before pressing approve, but if there is something I'm missing and that's the wrong idea then I'll approve this one.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1311,17 +1357,18 @@ "requester": "andrzej-stencel", "pr_author": "Dylan-M", "review_state": "COMMENTED", + "root_timestamp": "2026-04-09T17:29:04Z", "body": "Thanks @Dylan-M for putting this together.\n\nLet's settle on the solution in the issue https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/47444 before moving forward with this PR.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1338,19 +1385,23 @@ "requester": "paulojmdias", "pr_author": "Dylan-M", "review_state": "APPROVED", + "root_timestamp": "2026-05-07T14:52:15Z", "body": "Overall LGTM, just a small nit.", - "role": "context", - "stability": null, - "recorded_label": null, + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - null, - "none", - null, - "none", - null + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", "no_author_action", "no_author_action" ] @@ -1362,17 +1413,18 @@ "requester": "andrzej-stencel", "pr_author": "Dylan-M", "review_state": "COMMENTED", + "root_timestamp": "2026-07-13T12:27:21Z", "body": "My strong preference is still to use the feature gate. The File Log receiver is widely used in big deployments where seemingly simple change of updating a config might require coordination between multiple teams. A staged rollout with a feature gate makes upgrading less painful for users.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1389,17 +1441,18 @@ "requester": "paulojmdias", "pr_author": "skreuzer", "review_state": null, + "root_timestamp": "2026-04-13T23:15:23Z", "body": "Fixes https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/47573", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1410,50 +1463,52 @@ ] }, { - "id": "pr-issue-comment-5040503121", + "id": "pr-review-4103555936", "repo": "opentelemetry-collector-contrib", "pull_request": 47574, - "requester": "pjanotti", + "requester": "alliasgher", "pr_author": "skreuzer", - "review_state": null, - "body": "@skreuzer thanks to @paulojmdias this was already re-opened, ping us if you make progress on this PR.", + "review_state": "COMMENTED", + "root_timestamp": "2026-04-14T05:37:34Z", + "body": "lgtm", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-review-4103555936", + "id": "pr-issue-comment-5040503121", "repo": "opentelemetry-collector-contrib", "pull_request": 47574, - "requester": "alliasgher", + "requester": "pjanotti", "pr_author": "skreuzer", - "review_state": "COMMENTED", - "body": "lgtm", + "review_state": null, + "root_timestamp": "2026-07-22T00:34:57Z", + "body": "@skreuzer thanks to @paulojmdias this was already re-opened, ping us if you make progress on this PR.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1470,17 +1525,18 @@ "requester": "atoulme", "pr_author": "dherges", "review_state": null, + "root_timestamp": "2026-04-23T00:57:15Z", "body": "Change seems fine, doc only.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1497,17 +1553,18 @@ "requester": "atoulme", "pr_author": "dherges", "review_state": null, + "root_timestamp": "2026-06-19T00:22:50Z", "body": "@dmitryax please review as codeowner, thanks!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1524,17 +1581,18 @@ "requester": "atoulme", "pr_author": "dherges", "review_state": null, + "root_timestamp": "2026-06-23T15:20:46Z", "body": "> @atoulme do i need to do anything?\r\n\r\njust need a review by @dmitryax", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1551,17 +1609,18 @@ "requester": "atoulme", "pr_author": "michaelalang", "review_state": null, + "root_timestamp": "2026-04-23T01:31:54Z", "body": "Please add a changelog and mark ready for review again.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1578,17 +1637,18 @@ "requester": "paulojmdias", "pr_author": "michaelalang", "review_state": null, + "root_timestamp": "2026-06-22T14:38:50Z", "body": "@asweet-confluent, can you please review as codeowner?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1605,24 +1665,81 @@ "requester": "asweet-confluent", "pr_author": "michaelalang", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-10T19:26:02Z", "body": "See my comment [here](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/47849/changes#r3561462235) - we can't merge this, not in this state. I'll follow up in https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/47845.", "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4194539341", + "repo": "opentelemetry-collector-contrib", + "pull_request": 47972, + "requester": "rogercoll", + "pr_author": "salvatore-campagna", + "review_state": "COMMENTED", + "root_timestamp": "2026-04-29T08:17:24Z", + "body": "Nice work!", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-4202287070", + "repo": "opentelemetry-collector-contrib", + "pull_request": 47972, + "requester": "rogercoll", + "pr_author": "salvatore-campagna", + "review_state": "APPROVED", + "root_timestamp": "2026-04-30T03:39:21Z", + "body": "LGTM! It would be great having a storage analysis of this improvement before moving the feature gate to beta 🎉", + "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "none", - "author" + "no_author_action", + "author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "author_action", - "author_action", "no_author_action", - "author_action" + "author_action", + "no_author_action" ] }, { @@ -1632,17 +1749,18 @@ "requester": "rogercoll", "pr_author": "salvatore-campagna", "review_state": null, + "root_timestamp": "2026-05-15T03:50:17Z", "body": "@dmitryax @braydonk Any thoughts on these changes? (I am primarily in favor as removes the float64 arithmetic noise which ends up reducing the storage costs while maintaining the precision)", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1659,17 +1777,18 @@ "requester": "dmitryax", "pr_author": "salvatore-campagna", "review_state": null, + "root_timestamp": "2026-05-29T22:27:48Z", "body": "We touched on this in the System Semantic Conventions SIG yesterday. \r\n\r\nI have to push back on this. I should have flagged concerns on #46153 before approving it, and this PR builds further on the same approach while adding much more complexity. I don't think this complexity can be justified.\r\n\r\nFrom my point of view, rounding a float's mantissa is meaningless by design as it's encoded as binary fractions, not as decimals. The PRs call the additional digits \"arithmetic noise\", but we cannot remove that noise we just push it further away behind more zeroes, e.g. 3.3333333333...4 becomes something like 3.330000000000...03232434\r\n\r\nIf users want values rounded this way, the transform processor is a better place, where it can be implement an OTTL function. Receivers should always optimize for accuracy of the emitted values not for their representation.\r\n\r\nI'd even suggest we also revisit #46153. @braydonk WDYT?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1686,20 +1805,22 @@ "requester": "rogercoll", "pr_author": "salvatore-campagna", "review_state": null, + "root_timestamp": "2026-06-05T07:35:35Z", "body": "During the System SIG on 04/06/2026 we discussed whether https://github.com/open-telemetry/opentelemetrycollector-contrib/pull/46153 could be moved into a processor or OTTL function. The core challenge is that the PR does not apply fixed-decimal truncation, it derives the correct number of significant digits from the magnitude of the original integer inputs, so the rounding is context-aware and cannot be reconstructed once the float64 is emitted.\r\n\r\n Two cases:\r\n - `precision.Ratio`: used for utilization ratios, it could in principle become an OTTL function, but it would require the receiver to expose raw usage integers, so the function has both operands available. This means every utilization metric would need explicit pipeline configuration (usage values) to compute and store the result into a new utilization metric, making default setups verbose and leaving users who don't opt in with the values with false precision.\r\n - `precision.Scale`: cannot be moved downstream. The rounding corrects noise introduced by the receiver's own time-unit conversion (e.g. ticks → seconds). That information is lost once the float64 is emitted, a processor has no way to recover it. The only alter ...[truncated]", - "role": "context", - "stability": null, + "role": "scored", + "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "author", - null + "author_action", + "author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ - "no_author_action", + "author_action", + "author_action", "no_author_action", "no_author_action", "author_action" @@ -1712,24 +1833,25 @@ "requester": "rogercoll", "pr_author": "salvatore-campagna", "review_state": null, + "root_timestamp": "2026-06-22T08:12:42Z", "body": "Not stale. During System WG SIG on 04/06/2026 it has discussed if there was any gopsutil feature to retrieve the raw cputicks using the package. It seems that now at the moment, but it could be extended using the `Ex` structs strategy, see https://github.com/shirou/gopsutil#ex-struct-from-v4245 As this PR is under a feature flag, the cpu ticks could be added into an `Ex` gopsutil struct in a follow-up PR", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", - "author_action" + "no_author_action" ] }, { @@ -1739,44 +1861,18 @@ "requester": "rogercoll", "pr_author": "salvatore-campagna", "review_state": null, + "root_timestamp": "2026-07-15T10:18:12Z", "body": "Friendly reminder for other codeowners @braydonk and @dmitryax", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4194539341", - "repo": "opentelemetry-collector-contrib", - "pull_request": 47972, - "requester": "rogercoll", - "pr_author": "salvatore-campagna", - "review_state": "COMMENTED", - "body": "Nice work!", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ "no_author_action", @@ -1787,23 +1883,24 @@ ] }, { - "id": "pr-review-4202287070", + "id": "pr-review-4288922298", "repo": "opentelemetry-collector-contrib", - "pull_request": 47972, - "requester": "rogercoll", - "pr_author": "salvatore-campagna", - "review_state": "APPROVED", - "body": "LGTM! It would be great having a storage analysis of this improvement before moving the feature gate to beta 🎉", + "pull_request": 47985, + "requester": "edmocosta", + "pr_author": "meldegwi", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-14T10:32:14Z", + "body": "Thanks for working on this @MohamedElDegwi! I'm still running a few tests but it looks good so far. To make reviews easier, could you please split these changes into separate PRs? one for the grammar, and another one for functions and contexts data paths? This functionally should be backward compatible so we shouldn't have any issues doing that. \n\nAs I mentioned, we also need to standardized the existing OTTL's context paths that are currently returning bare Go's slices instead of `pcommon.Slice`.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1814,23 +1911,24 @@ ] }, { - "id": "pr-issue-comment-4622170940", + "id": "pr-review-4355605896", "repo": "opentelemetry-collector-contrib", "pull_request": 47985, "requester": "edmocosta", "pr_author": "meldegwi", - "review_state": null, - "body": "I'm sorry for not checking it first, but I just realized while reviewing this PR that this standardization might limit our list support, and what we could possibly express as slices in the future. From one hand, it should be fine as the `pcommon.Slice` only uses the pdata standard data types, and we're constrained to that, but on the other hand, OTTL value model is wider than `pcommon.Slice`, supporting types like `time.Time`, `time.Duration`, `pcommon.SpanID`, `pcommon.TraceID`, and `pprofile.ProfileID`. If we move forward with this, we wouldn't be able create lists of them anymore (e.g `[Duration(\"1s\"), Duration(\"2m\")]`), even if the values are only being used to pass as arguments to functions calls/context paths.\r\n\r\nWDYT @TylerHelmuth @evan-bradley @bogdandrutu? I'm not sure anymore if we should continue with this change, and I'm curious to also hear your take on that.", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-25T12:39:14Z", + "body": "Thanks @MohamedElDegwi! I think we're almost there 🎉", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -1841,104 +1939,80 @@ ] }, { - "id": "pr-issue-comment-4928678934", + "id": "pr-issue-comment-4622170940", "repo": "opentelemetry-collector-contrib", "pull_request": 47985, - "requester": "TylerHelmuth", + "requester": "edmocosta", "pr_author": "meldegwi", "review_state": null, - "body": "I don't think we should limit our ability to make lists like `[Duration(\"1s\"), Duration(\"2m\")]` especially with the new lambda function support. It seems likely that a slice of non-pdata types could be returned from one of those functions. \r\n\r\nI like @meldegwi idea of trying to support both as long as it is not underperformant.", + "root_timestamp": "2026-06-04T12:33:34Z", + "body": "I'm sorry for not checking it first, but I just realized while reviewing this PR that this standardization might limit our list support, and what we could possibly express as slices in the future. From one hand, it should be fine as the `pcommon.Slice` only uses the pdata standard data types, and we're constrained to that, but on the other hand, OTTL value model is wider than `pcommon.Slice`, supporting types like `time.Time`, `time.Duration`, `pcommon.SpanID`, `pcommon.TraceID`, and `pprofile.ProfileID`. If we move forward with this, we wouldn't be able create lists of them anymore (e.g `[Duration(\"1s\"), Duration(\"2m\")]`), even if the values are only being used to pass as arguments to functions calls/context paths.\r\n\r\nWDYT @TylerHelmuth @evan-bradley @bogdandrutu? I'm not sure anymore if we should continue with this change, and I'm curious to also hear your take on that.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "author", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", - "author_action", + "no_author_action", "no_author_action", "no_author_action" ] }, { - "id": "pr-review-4288922298", + "id": "pr-issue-comment-4928678934", "repo": "opentelemetry-collector-contrib", "pull_request": 47985, - "requester": "edmocosta", + "requester": "TylerHelmuth", "pr_author": "meldegwi", - "review_state": "COMMENTED", - "body": "Thanks for working on this @MohamedElDegwi! I'm still running a few tests but it looks good so far. To make reviews easier, could you please split these changes into separate PRs? one for the grammar, and another one for functions and contexts data paths? This functionally should be backward compatible so we shouldn't have any issues doing that. \n\nAs I mentioned, we also need to standardized the existing OTTL's context paths that are currently returning bare Go's slices instead of `pcommon.Slice`.", + "review_state": null, + "root_timestamp": "2026-07-09T19:14:43Z", + "body": "I don't think we should limit our ability to make lists like `[Duration(\"1s\"), Duration(\"2m\")]` especially with the new lambda function support. It seems likely that a slice of non-pdata types could be returned from one of those functions. \r\n\r\nI like @meldegwi idea of trying to support both as long as it is not underperformant.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ - "author_action", "author_action", "author_action", + "no_author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4355605896", - "repo": "opentelemetry-collector-contrib", - "pull_request": 47985, - "requester": "edmocosta", - "pr_author": "meldegwi", - "review_state": "COMMENTED", - "body": "Thanks @MohamedElDegwi! I think we're almost there 🎉", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ + "author_action", + "author_action", "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action" ] }, { - "id": "pr-issue-comment-4422101515", + "id": "pr-review-4222096037", "repo": "opentelemetry-collector-contrib", "pull_request": 48017, - "requester": "atoulme", + "requester": "songy23", "pr_author": "Frapschen", - "review_state": null, - "body": "Please fix conflicts", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-04T17:31:07Z", + "body": "needs `make gotidy`", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -1949,50 +2023,52 @@ ] }, { - "id": "pr-issue-comment-4532371414", + "id": "pr-review-4252211412", "repo": "opentelemetry-collector-contrib", "pull_request": 48017, - "requester": "andrzej-stencel", + "requester": "jcreixell", "pr_author": "Frapschen", - "review_state": null, - "body": "> given that the old name still works, I think this is fine, but do we have a timeline for the full removal of the old name? we need to make sure that nothing will break on our side\r\n\r\n> @andrzej-stencel, any ETA on when the old name will be fully removed?\r\n\r\nThere is currently no specific plan on when to remove the deprecated names. I believe the consensus among the maintainers is to keep them for as long as possible. There's definitely no short-term plan to remove them.\r\n\r\nThis definitely needs a discussion on its own.", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-08T12:28:09Z", + "body": "given that the old name still works, I think this is fine, but do we have a timeline for the full removal of the old name? we need to make sure that nothing will break on our side", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-4222096037", + "id": "pr-issue-comment-4422101515", "repo": "opentelemetry-collector-contrib", "pull_request": 48017, - "requester": "songy23", + "requester": "atoulme", "pr_author": "Frapschen", - "review_state": "COMMENTED", - "body": "needs `make gotidy`", + "review_state": null, + "root_timestamp": "2026-05-11T15:24:56Z", + "body": "Please fix conflicts", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2003,30 +2079,31 @@ ] }, { - "id": "pr-review-4252211412", + "id": "pr-issue-comment-4532371414", "repo": "opentelemetry-collector-contrib", "pull_request": 48017, - "requester": "jcreixell", + "requester": "andrzej-stencel", "pr_author": "Frapschen", - "review_state": "COMMENTED", - "body": "given that the old name still works, I think this is fine, but do we have a timeline for the full removal of the old name? we need to make sure that nothing will break on our side", + "review_state": null, + "root_timestamp": "2026-05-25T07:23:27Z", + "body": "> given that the old name still works, I think this is fine, but do we have a timeline for the full removal of the old name? we need to make sure that nothing will break on our side\r\n\r\n> @andrzej-stencel, any ETA on when the old name will be fully removed?\r\n\r\nThere is currently no specific plan on when to remove the deprecated names. I believe the consensus among the maintainers is to keep them for as long as possible. There's definitely no short-term plan to remove them.\r\n\r\nThis definitely needs a discussion on its own.", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -2036,22 +2113,23 @@ "requester": "dashpole", "pr_author": "Frapschen", "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T15:20:42Z", "body": "~The documentation in is very helpful. I suggest adding a note indicating which version introduced this rename to make it easier for users to track when to expect the deprecation.~", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ + "no_author_action", "author_action", + "no_author_action", "author_action", + "author_action" + ], + "run_labels": [ + "no_author_action", "author_action", + "no_author_action", "author_action", "author_action" ] @@ -2063,17 +2141,18 @@ "requester": "atoulme", "pr_author": "Dylan-M", "review_state": null, + "root_timestamp": "2026-06-20T01:50:03Z", "body": "Please address conflicts.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2090,17 +2169,18 @@ "requester": "bogdan-st", "pr_author": "jeevan6996", "review_state": null, + "root_timestamp": "2026-05-30T01:15:37Z", "body": "So after a bit of reading around I found https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp#WithEndpointURL which I think does exactly what this PR implements. \r\nYou'd still need to join the extracted path with --otlp-http-url-path, but the parsing itself doesn't need to be reimplemented.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2117,17 +2197,18 @@ "requester": "atoulme", "pr_author": "ben-trans", "review_state": null, + "root_timestamp": "2026-05-31T06:28:14Z", "body": "Please fix the conflict and mark ready for review again.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2144,17 +2225,18 @@ "requester": "atoulme", "pr_author": "ben-trans", "review_state": null, + "root_timestamp": "2026-06-08T04:48:04Z", "body": "@jamesmoessis please review as codeowner", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2171,44 +2253,46 @@ "requester": "jamesmoessis", "pr_author": "ben-trans", "review_state": null, + "root_timestamp": "2026-07-17T02:08:59Z", "body": "Hey @ben-trans I had a look into your issue, it seems like it still occurs even when I rebase your branch on main, use the latest mdatagen. So I've raised a bug: https://github.com/open-telemetry/opentelemetry-collector/issues/15592.\r\n\r\nIn the meantime to unblock yourself, I _think_ you can still register the featuregate by hand by copying whatever the generated code is doing (see other components in the repo for prior art). I apologise for the inconvenience, hopefully it can be fixed soon.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "none" + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", - "author_action", - "no_author_action" + "no_author_action", + "author_action" ] }, { - "id": "pr-issue-comment-4735747446", + "id": "pr-review-4443967991", "repo": "opentelemetry-collector-contrib", "pull_request": 48223, "requester": "paulojmdias", "pr_author": "KyriosGN0", - "review_state": null, - "body": "@KyriosGN0, please fix the conflicts.\r\n\r\nIt is enough to create the issues to be tackled later 👍", + "review_state": "COMMENTED", + "root_timestamp": "2026-06-06T22:56:45Z", + "body": "Thank you @KyriosGN0! Some notes that worth taking a look.\r\n\r\nIt is also missing the README.md update about this new feature. I also think it's worth taking a look at the detectors, which also do native retries (like EC2), and mark the options there as deprecated for future removal (also creating follow-up issues for that)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2219,23 +2303,24 @@ ] }, { - "id": "pr-review-4443967991", + "id": "pr-issue-comment-4735747446", "repo": "opentelemetry-collector-contrib", "pull_request": 48223, "requester": "paulojmdias", "pr_author": "KyriosGN0", - "review_state": "COMMENTED", - "body": "Thank you @KyriosGN0! Some notes that worth taking a look.\r\n\r\nIt is also missing the README.md update about this new feature. I also think it's worth taking a look at the detectors, which also do native retries (like EC2), and mark the options there as deprecated for future removal (also creating follow-up issues for that)", + "review_state": null, + "root_timestamp": "2026-06-17T21:34:04Z", + "body": "@KyriosGN0, please fix the conflicts.\r\n\r\nIt is enough to create the issues to be tackled later 👍", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2252,17 +2337,18 @@ "requester": "paulojmdias", "pr_author": "KyriosGN0", "review_state": "APPROVED", + "root_timestamp": "2026-07-13T20:40:09Z", "body": "LGTM! Thank you!\n\n@dashpole, please give your review when you get a chance 🙏", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2279,24 +2365,25 @@ "requester": "MovieStoreGuy", "pr_author": "meebok", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-10T00:02:11Z", "body": "Waiting for sponsor", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -2306,17 +2393,18 @@ "requester": "michael-burt", "pr_author": "sigmaris", "review_state": null, + "root_timestamp": "2026-07-18T15:16:59Z", "body": "@sigmaris , if an intermediate cert has the same SAN / issuer / target I think we will end up with duplicate datapoints because we have no way to distinguish the intermediate cert from the leaf cert. Perhaps we need to add a fingerprint attribute or something? I am not sure, I have not deeply thought about it but there is a risk in some circumstances when intermediate certs \"look\" substantially similar to the leaf certificate.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2333,17 +2421,18 @@ "requester": "michael-burt", "pr_author": "sigmaris", "review_state": null, + "root_timestamp": "2026-07-20T15:46:53Z", "body": "Adding a fingerprint should not add any cardinality except for the case where we have clashing series. I don't think we can assume we won't hit instances where the intermediate and leaf certs look the same, it is mechanically possible and this receiver will be installed and enabled on millions of machines, so it is likely that we will hit this edge case I think. \r\n\r\nIs there a conventional hash or fingerprint that is part of the TLS spec we can use to distinguich clashing series, or would we just need to roll our own hash?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2360,17 +2449,18 @@ "requester": "michael-burt", "pr_author": "sigmaris", "review_state": null, + "root_timestamp": "2026-07-20T16:56:46Z", "body": "> I think it'd be better to use an SHA256 digest of the DER encoded certificate. \r\n\r\nIf we use this then wouldn't we have the same fingerprint for each cert in the chain? I think the entire chain is encoded in the DER, right?\r\n\r\n> @michael-burt Should the fingerprint be added by default as an attribute to all certificate metrics, or only when scrape_all_certs is enabled (and so there could be more than once certificate scraped)?\r\n\r\nWe could leave it off by default in all cases, document its existence and rationale, and give users the ability to enable the metric via config if they have a need for it.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2387,17 +2477,18 @@ "requester": "michael-burt", "pr_author": "sigmaris", "review_state": null, + "root_timestamp": "2026-07-20T18:00:12Z", "body": "> No, it's possible as each individual certificate in a chain is represented by a x509.Certificate and we can get its DER encoded bytes from [its Raw attribute](https://pkg.go.dev/crypto/x509#Certificate), and calculate the SHA256 of those bytes (only). So calculating a specific fingerprint for each individual certificate is doable.\r\n\r\nnice, we should add a test for uniqueness I think, I am wondering if we would need to hash some positional arg or something if other fields are identical, hopefully not though.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2414,17 +2505,18 @@ "requester": "adrielp", "pr_author": "nissessenap", "review_state": null, + "root_timestamp": "2026-06-23T12:55:47Z", "body": "@nissessenap - thanks for the contribution. please fix the govet errors.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2441,17 +2533,18 @@ "requester": "adrielp", "pr_author": "nissessenap", "review_state": null, + "root_timestamp": "2026-07-12T10:07:42Z", "body": "want to check-in on this. looks like builds were failing after the last fix. let's pull latest from main and kick off builds to make sure things pass. \r\n\r\nty for your patience on this!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2468,17 +2561,18 @@ "requester": "adrielp", "pr_author": "nissessenap", "review_state": null, + "root_timestamp": "2026-07-13T16:19:39Z", "body": "@nissessenap Please fix the lint issues: https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/runs/28465548065/job/84364801745?pr=48539\r\n\r\nAnd pull latest from main.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2495,17 +2589,18 @@ "requester": "adrielp", "pr_author": "nissessenap", "review_state": null, + "root_timestamp": "2026-07-22T12:35:59Z", "body": "Looks like the supervisor test failure is unrelated to this pull request.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2516,23 +2611,24 @@ ] }, { - "id": "pr-issue-comment-5014620665", + "id": "pr-review-4667555876", "repo": "opentelemetry-collector-contrib", "pull_request": 48559, - "requester": "yaten2302", + "requester": "MovieStoreGuy", "pr_author": "challahc", - "review_state": null, - "body": "/workflow-approve\r\n\r\nEDIT: Can someone approve the workflows here, ig I don't have the required permissions.", + "review_state": "APPROVED", + "root_timestamp": "2026-07-09T23:54:59Z", + "body": "All the changes make sense to me, I'll have the code owners give their final approval first.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2543,23 +2639,24 @@ ] }, { - "id": "pr-issue-comment-5100402046", + "id": "pr-review-4727964028", "repo": "opentelemetry-collector-contrib", "pull_request": 48559, - "requester": "singhvibhanshu", + "requester": "yaten2302", "pr_author": "challahc", - "review_state": null, - "body": "I think it would make more sense if we had a separate PR for `internal/aws` component and focus this one only on `awscloudwatchlogs` exporter.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-18T07:03:55Z", + "body": "Config schemas are out of date, you can run this - `make generate-schemas` and push the changes!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2570,25 +2667,26 @@ ] }, { - "id": "pr-review-4667555876", + "id": "pr-issue-comment-5014620665", "repo": "opentelemetry-collector-contrib", "pull_request": 48559, - "requester": "MovieStoreGuy", + "requester": "yaten2302", "pr_author": "challahc", - "review_state": "APPROVED", - "body": "All the changes make sense to me, I'll have the code owners give their final approval first.", + "review_state": null, + "root_timestamp": "2026-07-19T05:56:05Z", + "body": "/workflow-approve\r\n\r\nEDIT: Can someone approve the workflows here, ig I don't have the required permissions.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ "no_author_action", "no_author_action", "no_author_action", @@ -2597,23 +2695,52 @@ ] }, { - "id": "pr-review-4727964028", + "id": "pr-issue-comment-5100402046", "repo": "opentelemetry-collector-contrib", "pull_request": 48559, - "requester": "yaten2302", + "requester": "singhvibhanshu", "pr_author": "challahc", + "review_state": null, + "root_timestamp": "2026-07-28T05:40:40Z", + "body": "I think it would make more sense if we had a separate PR for `internal/aws` component and focus this one only on `awscloudwatchlogs` exporter.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4339116932", + "repo": "opentelemetry-collector-contrib", + "pull_request": 48565, + "requester": "swiatekm", + "pr_author": "briandavis-viz", "review_state": "CHANGES_REQUESTED", - "body": "Config schemas are out of date, you can run this - `make generate-schemas` and push the changes!", + "root_timestamp": "2026-05-21T17:17:44Z", + "body": "I would really prefer to avoid this precheck hack. Is there no other binary we can use to probe this? The bbolt cli has some recovery related commands in it: https://github.com/etcd-io/bbolt/tree/main/cmd/bbolt/command. Surely one of them is immune to this panic.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2630,17 +2757,18 @@ "requester": "iblancasa", "pr_author": "briandavis-viz", "review_state": null, + "root_timestamp": "2026-05-25T16:11:55Z", "body": "I think we should add something to support last released version until https://github.com/etcd-io/bbolt/issues/1190 is finished. We can create a follow up pr to migrate when that happens.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2657,24 +2785,25 @@ "requester": "swiatekm", "pr_author": "briandavis-viz", "review_state": null, + "root_timestamp": "2026-05-25T16:42:11Z", "body": "If what we need right now is spawning a collector subprocess with a secret init function, then I'm against and would rather wait for bbolt release.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "no_author_action", - "no_author_action", "author_action", - "no_author_action" + "author_action", + "author_action", + "author_action" ] }, { @@ -2684,24 +2813,25 @@ "requester": "VihasMakwana", "pr_author": "briandavis-viz", "review_state": null, + "root_timestamp": "2026-06-02T08:30:23Z", "body": "How do you guys feel to pinning bbolt version to https://github.com/etcd-io/bbolt/releases/tag/v1.5.0-rc.0 or https://github.com/etcd-io/bbolt/releases/tag/v1.5.0-beta.0?", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ + "author_action", "author_action", "no_author_action", "no_author_action", - "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -2711,23 +2841,24 @@ "requester": "swiatekm", "pr_author": "briandavis-viz", "review_state": null, + "root_timestamp": "2026-06-02T10:10:13Z", "body": "> How do you guys feel to pinning bbolt version to https://github.com/etcd-io/bbolt/releases/tag/v1.5.0-rc.0 or https://github.com/etcd-io/bbolt/releases/tag/v1.5.0-beta.0?\r\n\r\nI'd rather wait until there's a final release. But we can definitely work on PRs using the beta in the meantime.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "author", - "none" - ], - "run_labels": [ + "no_author_action", + "author_action", "author_action", "no_author_action", + "no_author_action" + ], + "run_labels": [ "no_author_action", "author_action", + "author_action", + "no_author_action", "no_author_action" ] }, @@ -2738,17 +2869,18 @@ "requester": "iblancasa", "pr_author": "briandavis-viz", "review_state": null, + "root_timestamp": "2026-07-03T07:01:37Z", "body": "@briandavis-viz bbolt was released. I think we are ok to go with this PR.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2765,71 +2897,18 @@ "requester": "iblancasa", "pr_author": "briandavis-viz", "review_state": null, + "root_timestamp": "2026-07-20T08:55:15Z", "body": "@briandavis-viz are you still interested on working on the issue? I can take your commits and continue if you are ok with that.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" - ] - }, - { - "id": "pr-review-4339116932", - "repo": "opentelemetry-collector-contrib", - "pull_request": 48565, - "requester": "swiatekm", - "pr_author": "briandavis-viz", - "review_state": "CHANGES_REQUESTED", - "body": "I would really prefer to avoid this precheck hack. Is there no other binary we can use to probe this? The bbolt cli has some recovery related commands in it: https://github.com/etcd-io/bbolt/tree/main/cmd/bbolt/command. Surely one of them is immune to this panic.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-4918449025", - "repo": "opentelemetry-collector-contrib", - "pull_request": 48618, - "requester": "antonblock", - "pr_author": "codeboten", - "review_state": null, - "body": "> Thanks for the reviews @VihasMakwana @antonblock, should be good to go now\r\n\r\nIt looks like the expected metrics in integration tests need to be updated", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -2846,44 +2925,46 @@ "requester": "antonblock", "pr_author": "codeboten", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-24T20:30:14Z", "body": "Looks good, had two requests to get checks passing", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "none", - "author" + "no_author_action", + "author_action", + "author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", "author_action", + "author_action", "no_author_action", - "author_action" + "no_author_action" ] }, { - "id": "pr-issue-comment-4607444877", + "id": "pr-issue-comment-4918449025", "repo": "opentelemetry-collector-contrib", - "pull_request": 48626, - "requester": "ps48", - "pr_author": "harshitt13", + "pull_request": 48618, + "requester": "antonblock", + "pr_author": "codeboten", "review_state": null, - "body": "Hi @harshitt1, the Otel-v1 PR is merged now can you please rebase your PRand update tests for otel-v1 logs and traces ingested in opensearch? also another question: does the integration test run with the github CI?", + "root_timestamp": "2026-07-08T19:24:13Z", + "body": "> Thanks for the reviews @VihasMakwana @antonblock, should be good to go now\r\n\r\nIt looks like the expected metrics in integration tests need to be updated", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2900,17 +2981,18 @@ "requester": "chatgpt-codex-connector", "pr_author": "harshitt13", "review_state": "COMMENTED", + "root_timestamp": "2026-05-25T10:45:45Z", "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `117f0ded48`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2927,17 +3009,18 @@ "requester": "ps48", "pr_author": "harshitt13", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-05-27T06:01:04Z", "body": "Thanks for tackling this, the testcontainers scaffolding is solid and this is the right direction. A few things need addressing before merge:\n\n1. The test isn't actually exercising `otel-v1`. I pulled the branch and ran go test tags=integration -run TestIntegration_OtelV1Mapping it passes in ~32s, but the resulting index uses the ss4o schema (fields like attributes.data_stream.*, status.code as text) rather than otel-v1 (which should have serviceName, durationInNanos, traceGroup, etc.). This happens because the MappingOTelV1 enum lives in #48612, which hasn't merged yet. Without it, cfg.Mode = \"otel-v1\" silently falls through to the default ss4o encoder. The green test is a false positive.\n\n2. The timestamp assertion encodes the bug it should catch. Issue #48615 exists because OpenSearch demotes date_nanos → date when no index template is present. Asserting typeValue == \"date\" means the test passes precisely when the precision regression is active the opposite of what we want.\n\n3. PR description and changelog overstate scope. The mention of \"unit tests validating successful requests, permanent errors, and retryable errors\" describes tests already on main this PR renames integration ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -2947,6 +3030,34 @@ "author_action" ] }, + { + "id": "pr-issue-comment-4607444877", + "repo": "opentelemetry-collector-contrib", + "pull_request": 48626, + "requester": "ps48", + "pr_author": "harshitt13", + "review_state": null, + "root_timestamp": "2026-06-02T22:17:20Z", + "body": "Hi @harshitt1, the Otel-v1 PR is merged now can you please rebase your PRand update tests for otel-v1 logs and traces ingested in opensearch? also another question: does the integration test run with the github CI?", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-5090446009", "repo": "opentelemetry-collector-contrib", @@ -2954,17 +3065,18 @@ "requester": "mx-psi", "pr_author": "iblancasa", "review_state": null, + "root_timestamp": "2026-07-27T10:55:54Z", "body": "Sorry for the delay, I left a comment on the related issue", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -2981,24 +3093,25 @@ "requester": "crobert-1", "pr_author": "avadla", "review_state": null, + "root_timestamp": "2026-05-29T18:16:47Z", "body": "_Converting to draft for now to [discuss further](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/48344#issuecomment-4578438607) in issue._", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -3008,17 +3121,18 @@ "requester": "crobert-1", "pr_author": "avadla", "review_state": "COMMENTED", + "root_timestamp": "2026-06-26T21:42:24Z", "body": "Please add more thorough testing for this that proves the full text comes through as expected after obfuscate when enabled", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3029,23 +3143,24 @@ ] }, { - "id": "pr-issue-comment-4600521290", + "id": "pr-review-4380645795", "repo": "opentelemetry-collector-contrib", "pull_request": 48663, - "requester": "ChrsMark", + "requester": "krisztianfekete", "pr_author": "kangyili", - "review_state": null, - "body": "> Update the k8sobjects receiver to use the newly implemented interface instead of the old one.\r\n\r\nThank's @kangyili, can you provide a short update/summary of what is the proposal for this so as we don't lose that information? (the 2 threads that it was discussed will be resolved, so let's get to the summary of those discussions)\r\n\r\nI would like to clarify if we will have breaking changes in the behaviour of the `k8sobjects` receiver and if so which those will be.\r\nAlso will we need to update the `k8sevents` receiver accordingly too? \r\n\r\nOnce we are aligned on the above, I will try to find the time to review the first PR soon.", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-28T12:04:04Z", + "body": "I like where this is going, thank you for working on this!\nAdded minor comments/questions.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3056,83 +3171,87 @@ ] }, { - "id": "pr-issue-comment-4630466063", + "id": "pr-review-4387662933", "repo": "opentelemetry-collector-contrib", "pull_request": 48663, "requester": "ChrsMark", "pr_author": "kangyili", - "review_state": null, - "body": "Thank's for the [summary](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/48663#issuecomment-4601249613) @kangyili! I think I agree with that proposal which essentially only removes the `resource_version` option. Since we can ensure that the user experience is not changed other than this removal and that checkpoints are honoured through the `storage` setting, I support the proposal.\r\n\r\nI don't think we need to make this new implementation configurable and an implementation plan like https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/48663#issuecomment-4600125637 would be fine. I'm not sure how much time I will have in the following weeks to review this but I don't want to block this if other code-owners are available to review :).", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-29T07:55:26Z", + "body": "Thank's for the PR. I would like to understand first how this will affect the user experience specially when we are deprecating existing settings that were used to server specific needs. In addition, we might need to split the PR into smaller ones once we have agreement, i.e. one for the internal lib's changes and 2 follow ups to surface the changes in the components (if needed). \n\nBTW, I wonder why the components' code need to change. Shouldn't that change only be an implementation detail that only affect the underlying internal library without changing anything on the components' API?\n\n/cc @dhruv-shah-sumo please take look since this affects the `storage` part you recently added.", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-4380645795", + "id": "pr-issue-comment-4600521290", "repo": "opentelemetry-collector-contrib", "pull_request": 48663, - "requester": "krisztianfekete", + "requester": "ChrsMark", "pr_author": "kangyili", - "review_state": "COMMENTED", - "body": "I like where this is going, thank you for working on this!\nAdded minor comments/questions.", - "role": "context", - "stability": null, - "recorded_label": null, + "review_state": null, + "root_timestamp": "2026-06-02T08:48:44Z", + "body": "> Update the k8sobjects receiver to use the newly implemented interface instead of the old one.\r\n\r\nThank's @kangyili, can you provide a short update/summary of what is the proposal for this so as we don't lose that information? (the 2 threads that it was discussed will be resolved, so let's get to the summary of those discussions)\r\n\r\nI would like to clarify if we will have breaking changes in the behaviour of the `k8sobjects` receiver and if so which those will be.\r\nAlso will we need to update the `k8sevents` receiver accordingly too? \r\n\r\nOnce we are aligned on the above, I will try to find the time to review the first PR soon.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - null, - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action", "author_action" ] }, { - "id": "pr-review-4387662933", + "id": "pr-issue-comment-4630466063", "repo": "opentelemetry-collector-contrib", "pull_request": 48663, "requester": "ChrsMark", "pr_author": "kangyili", - "review_state": "COMMENTED", - "body": "Thank's for the PR. I would like to understand first how this will affect the user experience specially when we are deprecating existing settings that were used to server specific needs. In addition, we might need to split the PR into smaller ones once we have agreement, i.e. one for the internal lib's changes and 2 follow ups to surface the changes in the components (if needed). \n\nBTW, I wonder why the components' code need to change. Shouldn't that change only be an implementation detail that only affect the underlying internal library without changing anything on the components' API?\n\n/cc @dhruv-shah-sumo please take look since this affects the `storage` part you recently added.", + "review_state": null, + "root_timestamp": "2026-06-05T10:13:18Z", + "body": "Thank's for the [summary](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/48663#issuecomment-4601249613) @kangyili! I think I agree with that proposal which essentially only removes the `resource_version` option. Since we can ensure that the user experience is not changed other than this removal and that checkpoints are honoured through the `storage` setting, I support the proposal.\r\n\r\nI don't think we need to make this new implementation configurable and an implementation plan like https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/48663#issuecomment-4600125637 would be fine. I'm not sure how much time I will have in the following weeks to review this but I don't want to block this if other code-owners are available to review :).", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -3142,17 +3261,18 @@ "requester": "carsonip", "pr_author": "dmfallak", "review_state": "COMMENTED", + "root_timestamp": "2026-06-19T11:05:54Z", "body": "thanks. The last time I tried implementing sharding locally, I was not able to prove that it resolves a bottleneck. Do you have benchmark numbers that would demonstrate the difference?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3169,24 +3289,25 @@ "requester": "carsonip", "pr_author": "dmfallak", "review_state": "COMMENTED", + "root_timestamp": "2026-07-01T18:01:22Z", "body": "Thanks! At a high level I like the idea of sharding, as we'll eventually need that because of perf. On the other hand I appreciate reasoning behind the single background loop introduced in #43671 by code owner @csmarchbanks which made the code much simpler.\n\nIf you get buy in from @csmarchbanks it'll help drive the PR forward. The bottom line is we'll need to be conscious about the additional complexity from this design decision.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", + "no_author_action", + "no_author_action", "no_author_action", "author_action", - "author_action" + "no_author_action" ] }, { @@ -3196,17 +3317,18 @@ "requester": "csmarchbanks", "pr_author": "dmfallak", "review_state": "COMMENTED", + "root_timestamp": "2026-07-01T22:53:05Z", "body": "At a high level I am also happy with a sharded approach. That was one of my ideas for how to improve the TSP after the last refactor if I came across additional bottlenecks.\n\nThat said, my initial thought is to have sharding be fairly transparent to users. Is there a reason anyone should run in non-sharded mode if throughput is better when sharded? Ideally we could even calculate and rebalance shards dynamically in response to load.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3223,17 +3345,18 @@ "requester": "csmarchbanks", "pr_author": "dmfallak", "review_state": "COMMENTED", + "root_timestamp": "2026-07-13T14:46:22Z", "body": "Just a quick comment, I'll get a full review in soon! Happy to have auto sizing of shards be in a follow up PR.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3250,17 +3373,18 @@ "requester": "carsonip", "pr_author": "iblancasa", "review_state": "COMMENTED", + "root_timestamp": "2026-07-16T17:51:35Z", "body": "thanks! if we're going to add counters for operation errors, what about adding counter for operations with outcome={success,failure} dimension? Then we can also infer that things are working even when error stays 0", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3277,17 +3401,18 @@ "requester": "carsonip", "pr_author": "iblancasa", "review_state": "APPROVED", + "root_timestamp": "2026-07-23T14:29:34Z", "body": "lgtm thanks!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3304,17 +3429,18 @@ "requester": "dashpole", "pr_author": "PySheriff", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T15:56:13Z", "body": "The fix correctly addresses the nil-pointer dereference in the method by delegating to , which is designed to be nil-safe. The addition of and provides appropriate regression testing for the reported issue. The changes look correct and well-justified.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3331,17 +3457,18 @@ "requester": "ebrdarSplunk", "pr_author": "vishalmore90", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-27T14:26:56Z", "body": "Would you be able to add a test? `metricRows` currently has no direct coverage — every scraper test uses `fakeDbClient`, so the real query path (and this fix) isn't exercised. A go-sqlmock-based test asserting ExpectationsWereMet() would fail if the rows aren't closed and would guard against regressions.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3358,24 +3485,25 @@ "requester": "atoulme", "pr_author": "MikeGoldsmith", "review_state": null, + "root_timestamp": "2026-07-17T16:14:45Z", "body": "It'd be good to get this into main before the next release so we consolidate changes in one release.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ "author_action", "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -3385,17 +3513,18 @@ "requester": "mwear", "pr_author": "basti1302", "review_state": "APPROVED", + "root_timestamp": "2026-07-20T16:58:48Z", "body": "Would like to see codeowners' thoughts on multi-cluster behavior, but LGTM.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3412,17 +3541,18 @@ "requester": "MikeGoldsmith", "pr_author": "dmytrohysht", "review_state": "APPROVED", + "root_timestamp": "2026-07-27T14:57:56Z", "body": "Thanks @dmytrohysht - I took a look at this alongside #49721 and I think this looks like the right approach.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3439,17 +3569,18 @@ "requester": "VihasMakwana", "pr_author": "darkknight8670", "review_state": null, + "root_timestamp": "2026-07-20T13:37:13Z", "body": "@darkknight8670 Does the older database keep working in case new one has corrupted?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3466,17 +3597,18 @@ "requester": "chatgpt-codex-connector", "pr_author": "harshitt13", "review_state": "COMMENTED", + "root_timestamp": "2026-07-18T10:16:57Z", "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `a0137cea99`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3493,21 +3625,22 @@ "requester": "meldegwi", "pr_author": "harshitt13", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-21T13:09:31Z", "body": "Hi @harshitt13, Nice work overall, just a few comments for your consideration :)", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "no_author_action", + "author_action", "no_author_action", "no_author_action", "no_author_action" @@ -3520,17 +3653,18 @@ "requester": "avy252004", "pr_author": "floze-the-genius", "review_state": null, + "root_timestamp": "2026-07-19T16:16:56Z", "body": "@floze-the-genius you havent check the `I, a human, wrote this pull request description myself` box and `easycla` sign in is also pending.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3541,23 +3675,24 @@ ] }, { - "id": "pr-issue-comment-5095401678", + "id": "pr-review-4742990669", "repo": "opentelemetry-collector-contrib", "pull_request": 49755, - "requester": "dashpole", + "requester": "paulojmdias", "pr_author": "khushijain21", - "review_state": null, - "body": "I generally prefer adding the new field without any restrictions, and putting the removal of the old field behind a feature gate to deprecate it slowly.", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-21T09:07:08Z", + "body": "Shouldn't we update the README.md with the options and support for `http` config parameter?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3568,23 +3703,24 @@ ] }, { - "id": "pr-review-4742990669", + "id": "pr-issue-comment-5095401678", "repo": "opentelemetry-collector-contrib", "pull_request": 49755, - "requester": "paulojmdias", + "requester": "dashpole", "pr_author": "khushijain21", - "review_state": "COMMENTED", - "body": "Shouldn't we update the README.md with the options and support for `http` config parameter?", + "review_state": null, + "root_timestamp": "2026-07-27T18:45:25Z", + "body": "I generally prefer adding the new field without any restrictions, and putting the removal of the old field behind a feature gate to deprecate it slowly.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3601,17 +3737,18 @@ "requester": "songy23", "pr_author": "evan-bradley", "review_state": "COMMENTED", + "root_timestamp": "2026-07-20T16:59:24Z", "body": "> Generated code is out of date for group 'extension', please run \"make generate\" and commit the changes in this PR.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3628,17 +3765,18 @@ "requester": "atoulme", "pr_author": "evan-bradley", "review_state": "APPROVED", + "root_timestamp": "2026-07-21T18:05:04Z", "body": "LGTM", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3655,17 +3793,18 @@ "requester": "douglascamata", "pr_author": "dpaasman00", "review_state": null, + "root_timestamp": "2026-07-21T08:43:05Z", "body": "@dpaasman00 need a rebase here after the extension host interface fix.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3682,17 +3821,18 @@ "requester": "chatgpt-codex-connector", "pr_author": "ogulcanaydogan", "review_state": "COMMENTED", + "root_timestamp": "2026-07-27T15:27:47Z", "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `5444f3db4f`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3709,17 +3849,18 @@ "requester": "paulojmdias", "pr_author": "alliasgher", "review_state": null, + "root_timestamp": "2026-07-22T08:46:12Z", "body": "PTAL into CI issues 👍", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3736,17 +3877,18 @@ "requester": "ebrdarSplunk", "pr_author": "alliasgher", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-22T09:36:06Z", "body": "Thanks for the fix — this addresses a real crash path our team has hit. A few notes:\n\nCorrectness: The `LEFT JOIN → INNER JOIN` change is semantically equivalent here since the existing `WHERE datname IS NOT NULL` clause was already filtering out unmatched rows. The `nil` guard in `scraper.go` is good defense-in-depth.\n\nCI: The misspell linter is failing on \"defence\" (line 435) — needs to be \"defense\" for US English.\n\nSuggestion: Adding a unit test that exercises the nil-guard code path (e.g., a synthetic row with a nil db.namespace key) to prove the skip behavior. The `WHERE datname IS NOT NULL` clause in the template is also now redundant after the `INNER JOIN` change — fine to leave but worth a comment or cleanup.\n\nI'll revisit once CI is green. Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3763,17 +3905,18 @@ "requester": "ebrdarSplunk", "pr_author": "Sprakhar97", "review_state": "APPROVED", + "root_timestamp": "2026-07-23T13:05:50Z", "body": "thanks for addressing internal feedback, happy to approve", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3790,17 +3933,18 @@ "requester": "th0masgl", "pr_author": "leocarrozzo", "review_state": null, + "root_timestamp": "2026-07-23T08:22:45Z", "body": "this feature would be awesome 👍", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3817,44 +3961,18 @@ "requester": "paulojmdias", "pr_author": "leocarrozzo", "review_state": null, + "root_timestamp": "2026-07-23T09:29:12Z", "body": "Thanks for the PR @leocarrozzo, however, the component still does not have a sponsor, and that is mandatory for adopting it.\r\n\r\nPlease also look into the [new components donation guidelines](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/docs/new-components.md), and this PR does not seem to follow them.\r\n\r\nI suggest you join a collector SIG meeting to discuss the issue and ask for sponsorship and/or reach out to the team in the #otel-collector-dev Slack channel.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-5108371622", - "repo": "opentelemetry-collector-contrib", - "pull_request": 49832, - "requester": "geekdave", - "pr_author": "bgola-signalfx", - "review_state": null, - "body": "@bgola-signalfx Thanks for the contribution! I appreciate your help in helping to make Oracle's Resource Detection Processor more compliant with the semantic conventions. A few questions and asks:\r\n\r\n1. The PR description has a \"tracking issue\" link that just points back to the same PR. Could you please open an issue that describes the problem being fixed? Or if the PR is self-documenting, better just to remove that section rather than have a self-referential PR link.\r\n\r\n3. I noticed that the Oracle Cloud detector already provides `host.id` which has the same source for its value:\r\n\r\n```\r\n\td.rb.SetCloudResourceID(compute.HostID)\r\n//...snip...\r\n\td.rb.SetHostID(compute.HostID)\r\n```\r\n\r\nI'm curious about the precedent for this. I noticed that AWS, GCP, and Azure all set only `host.id` but not `cloud.resource_id`. Interestingly, I do see that IBM Cloud does emit both attributes, but they come from different sources so they do not get set to the same value ([see IBM's code here](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/ibmcloud/vpc/ibmcloud_vpc.go#L66-L67)).\r\n\r\nWould be good to call out if this duplica ...[truncated]", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -3871,17 +3989,18 @@ "requester": "paulojmdias", "pr_author": "bgola-signalfx", "review_state": "COMMENTED", + "root_timestamp": "2026-07-23T13:10:14Z", "body": "Can we please enrich the available E2E tests for oracle cloud with this new attribute detection? https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor/testdata/e2e/oraclecloud", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -3898,17 +4017,18 @@ "requester": "paulojmdias", "pr_author": "bgola-signalfx", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T10:00:37Z", "body": "LGTM, thank you! \n\n@geekdave, we need your review here please 🙏", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3925,17 +4045,18 @@ "requester": "dashpole", "pr_author": "bgola-signalfx", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T16:56:08Z", "body": "I would also like to see a codeowner take a look", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -3946,28 +4067,57 @@ ] }, { - "id": "pr-review-4800821838", + "id": "pr-issue-comment-5108371622", "repo": "opentelemetry-collector-contrib", "pull_request": 49832, "requester": "geekdave", "pr_author": "bgola-signalfx", - "review_state": "CHANGES_REQUESTED", - "body": "See above comment for requested changes/clarifications. Thanks!", + "review_state": null, + "root_timestamp": "2026-07-28T18:48:20Z", + "body": "@bgola-signalfx Thanks for the contribution! I appreciate your help in helping to make Oracle's Resource Detection Processor more compliant with the semantic conventions. A few questions and asks:\r\n\r\n1. The PR description has a \"tracking issue\" link that just points back to the same PR. Could you please open an issue that describes the problem being fixed? Or if the PR is self-documenting, better just to remove that section rather than have a self-referential PR link.\r\n\r\n3. I noticed that the Oracle Cloud detector already provides `host.id` which has the same source for its value:\r\n\r\n```\r\n\td.rb.SetCloudResourceID(compute.HostID)\r\n//...snip...\r\n\td.rb.SetHostID(compute.HostID)\r\n```\r\n\r\nI'm curious about the precedent for this. I noticed that AWS, GCP, and Azure all set only `host.id` but not `cloud.resource_id`. Interestingly, I do see that IBM Cloud does emit both attributes, but they come from different sources so they do not get set to the same value ([see IBM's code here](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/ibmcloud/vpc/ibmcloud_vpc.go#L66-L67)).\r\n\r\nWould be good to call out if this duplica ...[truncated]", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", - "no_author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4800821838", + "repo": "opentelemetry-collector-contrib", + "pull_request": 49832, + "requester": "geekdave", + "pr_author": "bgola-signalfx", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-28T18:50:44Z", + "body": "See above comment for requested changes/clarifications. Thanks!", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", "author_action", "author_action" ] @@ -3979,17 +4129,18 @@ "requester": "singhvibhanshu", "pr_author": "Atishyy27", "review_state": null, + "root_timestamp": "2026-07-25T15:19:39Z", "body": "Please fix the linter issue.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4006,17 +4157,18 @@ "requester": "sv-splunk", "pr_author": "Sprakhar97", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T12:31:49Z", "body": "looks good", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4033,17 +4185,18 @@ "requester": "paulojmdias", "pr_author": "pujitha24", "review_state": null, + "root_timestamp": "2026-07-27T15:12:11Z", "body": "@yaten2302, can you review it as a codeowner? Thank you 🙏", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4060,17 +4213,18 @@ "requester": "crobert-1", "pr_author": "ebrdarSplunk", "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T18:30:22Z", "body": "I'd strongly prefer to separate the `host.name` change from the rest of this PR, unless there's some reason it must be included here.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4081,50 +4235,52 @@ ] }, { - "id": "pr-issue-comment-5102017566", + "id": "pr-review-4795478894", "repo": "opentelemetry-collector-contrib", "pull_request": 49898, "requester": "ebrdarSplunk", "pr_author": "avadla", - "review_state": null, - "body": "@avadla also can you edit MR desc to be:\r\n\r\n\"Fixes {URL of Issue}\" on the same line, that way the issue is linked to the MR and it auto closes the issue once MR is merged?", + "review_state": "APPROVED", + "root_timestamp": "2026-07-28T08:49:11Z", + "body": "LGTM. Verified locally: `GOOS=windows go build/vet ./...` is clean, `TestComputeServiceInstanceID` passes with the new ComputerName-priority cases, and the golden files match (`CustomServer:1433` for the named instance; host-dependent value correctly ignored in the default test). The `ComputerName` branch is safely ordered below `DataSource/Server,` so direct-connection behavior is unchanged.", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-issue-comment-5108869609", + "id": "pr-issue-comment-5102017566", "repo": "opentelemetry-collector-contrib", "pull_request": 49898, "requester": "ebrdarSplunk", "pr_author": "avadla", "review_state": null, - "body": "@avadla done now, i think there were upstresam issues earlier that seem to have resolved, you can rerun the jobs by posting a comment on this mr with ```/rerun```", + "root_timestamp": "2026-07-28T08:54:31Z", + "body": "@avadla also can you edit MR desc to be:\r\n\r\n\"Fixes {URL of Issue}\" on the same line, that way the issue is linked to the MR and it auto closes the issue once MR is merged?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4135,23 +4291,24 @@ ] }, { - "id": "pr-review-4795478894", + "id": "pr-issue-comment-5108869609", "repo": "opentelemetry-collector-contrib", "pull_request": 49898, "requester": "ebrdarSplunk", "pr_author": "avadla", - "review_state": "APPROVED", - "body": "LGTM. Verified locally: `GOOS=windows go build/vet ./...` is clean, `TestComputeServiceInstanceID` passes with the new ComputerName-priority cases, and the golden files match (`CustomServer:1433` for the named instance; host-dependent value correctly ignored in the default test). The `ComputerName` branch is safely ordered below `DataSource/Server,` so direct-connection behavior is unchanged.", + "review_state": null, + "root_timestamp": "2026-07-28T19:41:03Z", + "body": "@avadla done now, i think there were upstresam issues earlier that seem to have resolved, you can rerun the jobs by posting a comment on this mr with ```/rerun```", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4168,17 +4325,18 @@ "requester": "douglascamata", "pr_author": "AmariahAK", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-28T14:22:54Z", "body": "Few comments.\n\n@AmariahAK I also noticed that you didn't follow the PR template, which also indicates to me that the PR description was written by your agent and not by yourself. \n\nPlease update the PR description so that it matches the template and ensure it's written in your own words, according to the [GenAI policy](https://github.com/open-telemetry/community/blob/main/policies/genai.md).", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4195,17 +4353,18 @@ "requester": "songy23", "pr_author": "mx-psi", "review_state": null, + "root_timestamp": "2026-07-28T18:27:10Z", "body": "Needs \"make generate-schemas\"", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4222,17 +4381,18 @@ "requester": "carsonip", "pr_author": "blakerouse", "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T14:50:26Z", "body": "thanks. qq about persistent queue test, the mock pq looks like the in memory queue implementation to me and doesn't seem to provide additional coverage over using in memory queue, or the actual persistent queue test coverage in https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/elasticsearchexporter/integrationtest .", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4249,23 +4409,25 @@ "requester": "carsonip", "pr_author": "blakerouse", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T17:12:15Z", "body": "approving to unblock, thanks for adding the tests. One comment about the allowMissingDocs", - "role": "context", - "stability": null, + "role": "scored", + "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - null, - "author", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "no_author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ] }, { @@ -4275,17 +4437,46 @@ "requester": "martincostello", "pr_author": "juliuskoval", "review_state": null, + "root_timestamp": "2026-03-29T11:43:23Z", "body": "> shouldn't we try to guard against self-referencing IEnumerables\r\n\r\nI think so, otherwise it would cause a stack overflow? Could just add a recursion limit to track such occurences.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4163356355", + "repo": "opentelemetry-dotnet", + "pull_request": 7015, + "requester": "martincostello", + "pr_author": "juliuskoval", + "review_state": "COMMENTED", + "root_timestamp": "2026-04-23T14:41:10Z", + "body": "Could you also extend the fuzz tests to cover this functionality please?", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4302,17 +4493,18 @@ "requester": "SalvoDeveloper", "pr_author": "juliuskoval", "review_state": null, + "root_timestamp": "2026-05-20T08:58:25Z", "body": "We are having trouble sending complex nested objects to an OpenTelemetryCollector. I have tested the fork of @juliuskoval by connecting NLog.Target.OpenTelemetryProtocol with the OpenTelemetry-dotnet. I only need to traslate the object into IEnumerable>, and the everything works. I would kindly ask you to merge this and release new version. This would be really important for us.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4329,17 +4521,18 @@ "requester": "martincostello", "pr_author": "juliuskoval", "review_state": null, + "root_timestamp": "2026-05-20T09:10:45Z", "body": "@SalvoDeveloper I'm waiting for at least one other approving review from one of the other maintainers before merging this. Once merged it will be part of the next release (which has no specific date at this time).\r\n\r\nAfter it's merged you can use consume prerelease builds from [MyGet](https://github.com/open-telemetry/opentelemetry-dotnet#releases) if you can't wait until then.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4356,17 +4549,18 @@ "requester": "rajkumar-rangaraj", "pr_author": "juliuskoval", "review_state": null, + "root_timestamp": "2026-06-09T00:36:06Z", "body": "Before merging, I'd like us to align on:\r\n \r\n 1. Is implicit type-sniffing the path we want, or should we wait for typed AnyValue API so we don't ship two redundant contracts?\r\n 2. How do we address Blanch's reference-aliasing concern from #6052 - should this require SDK-level deep-copy on span end?\r\n \r\n Strong support for the underlying use case, but want to avoid locking in behavior we can't revisit.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4383,44 +4577,18 @@ "requester": "martincostello", "pr_author": "juliuskoval", "review_state": null, + "root_timestamp": "2026-06-23T08:57:03Z", "body": "These changes seem reasonable to me. Raj is on PTO until August so let's wait on another +1 from another maintainer.\r\n\r\nCan you also update the CHANGELOGs as-appropriate please?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4163356355", - "repo": "opentelemetry-dotnet", - "pull_request": 7015, - "requester": "martincostello", - "pr_author": "juliuskoval", - "review_state": "COMMENTED", - "body": "Could you also extend the fuzz tests to cover this functionality please?", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -4437,17 +4605,18 @@ "requester": "rajkumar-rangaraj", "pr_author": "Kielek", "review_state": null, + "root_timestamp": "2026-04-17T04:17:53Z", "body": "@utpilla Could you please review this PR when you have a moment?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4464,17 +4633,18 @@ "requester": "utpilla", "pr_author": "Kielek", "review_state": null, + "root_timestamp": "2026-04-17T17:57:34Z", "body": "Before merging, I think we need to answer a core question: **how should the Metrics SDK handle non-finite values (NaN, +Inf, -Inf)?**\r\n\r\nRight now, we don't seem to have a deliberate answer. The behavior varies by instrument. Counters get their sum poisoned, explicit bucket histograms put `NaN` in the `+Inf` bucket, exponential histograms filter `NaN` from buckets but still corrupt `sum`/`min`/`max`, and gauges just store `NaN` directly. None of this is documented, and this PR would change behavior for some instruments but not others.\r\n\r\nThe spec ([Numerical limits handling](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#numerical-limits-handling:~:text=the%20SDK%20needs%20to%20handle%20NaNs%20and%20Infinites.)) says the SDK MUST handle `NaN`/`Inf` but leaves the *how* unspecified. For exponential histograms specifically, the [spec](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#base2-exponential-bucket-histogram-aggregation:~:text=Implementations%20SHOULD%20NOT%20incorporate%20non%2Dnormal%20values%20(i.e.%2C%20%2BInf%2C%20%2DInf%2C%20and%20NaNs)%20into%20the%20sum%2C%20min% ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4491,44 +4661,18 @@ "requester": "rajkumar-rangaraj", "pr_author": "Kielek", "review_state": null, + "root_timestamp": "2026-06-08T22:47:25Z", "body": "@Kielek how you are planning to handle this PR?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-4551885749", - "repo": "opentelemetry-dotnet", - "pull_request": 7227, - "requester": "Kielek", - "pr_author": "nabutabu", - "review_state": null, - "body": "Asked Codex/GPT5.5 to check this PR.\r\nBoth of them marked as P1. Could you please double check this feedback?\r\n\r\n# Review Notes and Unit Test Proposals for PR #7227\r\n\r\nI think there are two correctness risks worth covering with targeted unit tests.\r\n\r\n## Issue 1: Delta temporality is not correct when filtered streams change\r\n\r\nThe current fix spatially aggregates async cumulative counter values by updating the already-filtered `MetricPoint` with:\r\n\r\n```text\r\nexisting running value + incoming measurement value\r\n```\r\n\r\nThat works for simple cumulative export cases where the same underlying streams are reported every cycle. The problem is delta export. `MetricPoint.TakeSnapshot(outputDelta: true)` computes the delta from the collapsed aggregate:\r\n\r\n```text\r\ncurrent collapsed aggregate - previous collapsed aggregate\r\n```\r\n\r\nThat is not equivalent to summing per-stream deltas if one original measurement stream disappears or reappears between callbacks.\r\n\r\nExample:\r\n\r\n```text\r\nCollection 1:\r\n A = 10\r\n B = 10\r\n Collapsed value = 20\r\n\r\nCollection 2:\r\n A = 15\r\n B is absent\r\n Collapsed value = 15\r\n```\r\n\r\nIf the SDK diffs collapsed values, delta export becomes:\r\n\r\n```text\r\n15 - 20 = -5\r ...[truncated]", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -4545,17 +4689,18 @@ "requester": "cijothomas", "pr_author": "nabutabu", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-04-30T15:10:13Z", "body": "See\nhttps://github.com/open-telemetry/opentelemetry-dotnet/pull/7227/changes#r3168921622\n\nLet me know if I misunderstood the fix.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4572,17 +4717,18 @@ "requester": "cijothomas", "pr_author": "nabutabu", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-05-04T18:34:15Z", "body": "The current iteration looks very promising (thanks! This was indeed a hard problem!). \nRequesting changes to address below comment\nhttps://github.com/open-telemetry/opentelemetry-dotnet/pull/7227/changes#r3183554865\n\nAlso, we need to vastly improve test coverage when doing this fix- lot of potential edge cases. (I spotted only one about Exemplar value, but could be more)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4593,23 +4739,24 @@ ] }, { - "id": "pr-issue-comment-4583065244", + "id": "pr-issue-comment-4551885749", "repo": "opentelemetry-dotnet", - "pull_request": 7346, - "requester": "martincostello", - "pr_author": "saguiitay", + "pull_request": 7227, + "requester": "Kielek", + "pr_author": "nabutabu", "review_state": null, - "body": "The CLA needs to be signed.", + "root_timestamp": "2026-05-27T06:14:41Z", + "body": "Asked Codex/GPT5.5 to check this PR.\r\nBoth of them marked as P1. Could you please double check this feedback?\r\n\r\n# Review Notes and Unit Test Proposals for PR #7227\r\n\r\nI think there are two correctness risks worth covering with targeted unit tests.\r\n\r\n## Issue 1: Delta temporality is not correct when filtered streams change\r\n\r\nThe current fix spatially aggregates async cumulative counter values by updating the already-filtered `MetricPoint` with:\r\n\r\n```text\r\nexisting running value + incoming measurement value\r\n```\r\n\r\nThat works for simple cumulative export cases where the same underlying streams are reported every cycle. The problem is delta export. `MetricPoint.TakeSnapshot(outputDelta: true)` computes the delta from the collapsed aggregate:\r\n\r\n```text\r\ncurrent collapsed aggregate - previous collapsed aggregate\r\n```\r\n\r\nThat is not equivalent to summing per-stream deltas if one original measurement stream disappears or reappears between callbacks.\r\n\r\nExample:\r\n\r\n```text\r\nCollection 1:\r\n A = 10\r\n B = 10\r\n Collapsed value = 20\r\n\r\nCollection 2:\r\n A = 15\r\n B is absent\r\n Collapsed value = 15\r\n```\r\n\r\nIf the SDK diffs collapsed values, delta export becomes:\r\n\r\n```text\r\n15 - 20 = -5\r ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4620,23 +4767,24 @@ ] }, { - "id": "pr-issue-comment-4663401183", + "id": "pr-issue-comment-4583065244", "repo": "opentelemetry-dotnet", "pull_request": 7346, - "requester": "cijothomas", + "requester": "martincostello", "pr_author": "saguiitay", "review_state": null, - "body": "I haven't review this PR in detail but one comment to think though:\r\n1. I am unsure if we need to let end users worry about this option - it is adding more cognitive overhead to endusers when setting up OTel.\r\n2. it may be better to change the default itself to follow this. This will cause increased jitter due to re-allocations as things get warmed up, and then settles. But once in steady state, no re-allocation needed, as we don't ever reclaim the underlying array from the Dictionary.\r\n\r\nWould be good if this can be discussed in SIG too.", + "root_timestamp": "2026-05-30T14:14:26Z", + "body": "The CLA needs to be signed.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4647,23 +4795,80 @@ ] }, { - "id": "pr-issue-comment-4682527745", + "id": "pr-issue-comment-4663401183", "repo": "opentelemetry-dotnet", "pull_request": 7346, "requester": "cijothomas", "pr_author": "saguiitay", "review_state": null, - "body": "@saguiitay Would you be able to join the community call to discuss more on this? (I won't be able to join, unfortunately, but I'll share some thoughts in the issue itself)", + "root_timestamp": "2026-06-09T19:42:20Z", + "body": "I haven't review this PR in detail but one comment to think though:\r\n1. I am unsure if we need to let end users worry about this option - it is adding more cognitive overhead to endusers when setting up OTel.\r\n2. it may be better to change the default itself to follow this. This will cause increased jitter due to re-allocations as things get warmed up, and then settles. But once in steady state, no re-allocation needed, as we don't ever reclaim the underlying array from the Dictionary.\r\n\r\nWould be good if this can be discussed in SIG too.", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-4478488315", + "repo": "opentelemetry-dotnet", + "pull_request": 7346, + "requester": "cijothomas", + "pr_author": "saguiitay", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-11T16:04:59Z", + "body": "Please use the SIG meeting to discuss this more.\nI don't think we should expand the configuration to add this feature - its forcing end users to make yet another decision.\nIf the original pre-allocation is not preferred, then it is better to change that itself and make it the default behavior.", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" + ] + }, + { + "id": "pr-issue-comment-4682527745", + "repo": "opentelemetry-dotnet", + "pull_request": 7346, + "requester": "cijothomas", + "pr_author": "saguiitay", + "review_state": null, + "root_timestamp": "2026-06-11T16:05:53Z", + "body": "@saguiitay Would you be able to join the community call to discuss more on this? (I won't be able to join, unfortunately, but I'll share some thoughts in the issue itself)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4680,17 +4885,18 @@ "requester": "martincostello", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-06-11T17:44:39Z", "body": "That's probably not workable for you then, as I think that would make the SIG at 2200 for you (it's usually at 1900 for me and I'm in the UK).", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4707,17 +4913,18 @@ "requester": "martincostello", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-06-16T10:59:03Z", "body": "I've added it to [today's SIG agenda](https://docs.google.com/document/d/1yjjD6aBcLxlRazYrawukDgrhZMObwHARJbB9glWdHj8/edit?usp=sharing).", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4734,17 +4941,18 @@ "requester": "cijothomas", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-06-24T03:55:24Z", "body": "> I've added it to [today's SIG agenda](https://docs.google.com/document/d/1yjjD6aBcLxlRazYrawukDgrhZMObwHARJbB9glWdHj8/edit?usp=sharing).\r\n\r\n@martincostello was this discussed? Can you update if any decision was made.\r\n\r\n\r\n> if it's up to me, we keep the option for a while, gather feedback from users, and only enable it by default if it's proven in production. I'd hate changing the default behavior, and getting a backlash from users that we broke them.\r\n\r\n@saguiitay Thanks, this idea makes sense. (And OTEL_DOTNET_EXPERIMENTAL_METRICS_ENABLE_LAZY_ALLOCATION approach would mean only advanced users will need to make this decision, and after evaluation, we can in future make this the default).", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4761,22 +4969,23 @@ "requester": "martincostello", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-06-24T06:58:05Z", "body": "> @martincostello was this discussed? Can you update if any decision was made.\r\n\r\nYes, Itay joined the SIG call and myself and Alan discussed it. TL;DR was Itay was going to speak to Raj about it internally and then look to make an experimental opt-in to allow for it to be tested in the wild. I forget exactly what else we discussed, but it'll be in the recording.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "author", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", - "author_action", + "no_author_action", "no_author_action", "no_author_action" ] @@ -4788,22 +4997,23 @@ "requester": "cijothomas", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-06-25T09:56:25Z", "body": "> > @martincostello was this discussed? Can you update if any decision was made.\r\n> \r\n> Yes, Itay joined the SIG call and myself and Alan discussed it. TL;DR was Itay was going to speak to Raj about it internally and then look to make an experimental opt-in to allow for it to be tested in the wild. I forget exactly what else we discussed, but it'll be in the recording.\r\n\r\nGot it. I agree with this approach. The experimental opt-in is via ENV variables right? \r\n\r\n@saguiitay Can you make the opt-in via ENV variable, and fix CI. I'll help review.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", - "no_author_action", + "author_action", "author_action", "author_action" ] @@ -4815,17 +5025,18 @@ "requester": "martincostello", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-06-25T09:59:24Z", "body": "> The experimental opt-in is via ENV variables right?\r\n\r\nYep.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4842,17 +5053,18 @@ "requester": "cijothomas", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-07-15T10:19:50Z", "body": "@saguiitay Sorry, I am getting back to this now only - could you fix conflicts, and update the PR desc to reflect the current status?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4869,78 +5081,25 @@ "requester": "djj0809", "pr_author": "saguiitay", "review_state": null, + "root_timestamp": "2026-07-20T17:17:46Z", "body": "Thanks for working on this! This PR would help unblock our migration to OpenTelemetry. Could it please be prioritized for review and merge?", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", - "no_author_action" - ] - }, - { - "id": "pr-review-4478488315", - "repo": "opentelemetry-dotnet", - "pull_request": 7346, - "requester": "cijothomas", - "pr_author": "saguiitay", - "review_state": "CHANGES_REQUESTED", - "body": "Please use the SIG meeting to discuss this more.\nI don't think we should expand the configuration to add this feature - its forcing end users to make yet another decision.\nIf the original pre-allocation is not preferred, then it is better to change that itself and make it the default behavior.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-4751535635", - "repo": "opentelemetry-dotnet", - "pull_request": 7413, - "requester": "martincostello", - "pr_author": "stevejgordon", - "review_state": null, - "body": "I'm happy to defer if the consensus is to split this up, but as I've already reviewed it all I'd rather not review three new PRs that are all the same code 😄 (even if they're the same, still got to review them).", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -4950,17 +5109,18 @@ "requester": "martincostello", "pr_author": "stevejgordon", "review_state": "COMMENTED", + "root_timestamp": "2026-06-17T16:30:23Z", "body": "Overall approach here looks really good to me.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -4977,17 +5137,18 @@ "requester": "MikeGoldsmith", "pr_author": "stevejgordon", "review_state": "COMMENTED", + "root_timestamp": "2026-06-19T12:16:44Z", "body": "This looks pretty good and it's great to see declarative config work in the .NET SDK.\n\nWould you consider splitting this before it goes out of draft? Even setting tests aside (which are most of the diff), the 2k lines of source to add the package, the YAML reader, env substitution, the model, the flat-key converter, and the IConfiguration overlay wiring all at once is overwhelming.\n\nPRs of this size are hard to review with confidence and expect a reviewer to hold the whole pipeline in their head.\n\nI think breaking into these broader areas would be helpful:\n- package skeleton + public API surface + OTEL1006 plumbing\n- YAML parse to typed model (reader, substitution, file-format validation)\n- model to IConfiguration overlay (converter + DI wiring + precedence)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -4997,6 +5158,34 @@ "author_action" ] }, + { + "id": "pr-issue-comment-4751535635", + "repo": "opentelemetry-dotnet", + "pull_request": 7413, + "requester": "martincostello", + "pr_author": "stevejgordon", + "review_state": null, + "root_timestamp": "2026-06-19T12:24:56Z", + "body": "I'm happy to defer if the consensus is to split this up, but as I've already reviewed it all I'd rather not review three new PRs that are all the same code 😄 (even if they're the same, still got to review them).", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, { "id": "pr-review-4591276850", "repo": "opentelemetry-dotnet", @@ -5004,17 +5193,18 @@ "requester": "martincostello", "pr_author": "stevejgordon", "review_state": "APPROVED", + "root_timestamp": "2026-06-29T11:12:47Z", "body": "LGTM - just the question regarding publishing needs resolving.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5031,17 +5221,18 @@ "requester": "Kielek", "pr_author": "stevejgordon", "review_state": "COMMENTED", + "root_timestamp": "2026-06-30T07:06:27Z", "body": "Only technical check.\nSorry for late feedback, still need more time to understand full flow for this component,", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -5058,17 +5249,18 @@ "requester": "Kielek", "pr_author": "cijothomas", "review_state": null, + "root_timestamp": "2026-07-13T06:30:53Z", "body": "@cijothomas, I asked Codex /GPT 5.6 Sol. Briefly checked findings and it looks valid to me:\r\n\r\nFollowing comment is AI driven\r\n\r\n---------\r\n\r\nReviewed commit: [`2a53a4a`](https://github.com/open-telemetry/opentelemetry-dotnet/commit/2a53a4a09702fd223f701ccc3514b3ced3104f3e)\r\n\r\n## 1. Count batch success at exporter submission, not queue admission\r\n\r\nPriority: P1\r\n\r\n[`BatchLogRecordExportProcessor.cs:108`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/2a53a4a09702fd223f701ccc3514b3ced3104f3e/src/OpenTelemetry/Logs/Processor/BatchLogRecordExportProcessor.cs#L108)\r\nincrements the success counter immediately after `TryExport` enqueues the log\r\nrecord.\r\n\r\nThe semantic convention says that, for simple and batching processors, a log\r\nrecord is considered processed when it has been submitted to the exporter, not\r\nwhen the corresponding export call finishes. For the batching processor,\r\nsubmission happens later on the worker thread. The current implementation can\r\ntherefore report records as successfully processed while they are still queued.\r\nIf draining does not complete, some of those records may never be submitted to\r\nthe exporter.\r\n\r\nThe successful increment should happen ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5085,24 +5277,25 @@ "requester": "martincostello", "pr_author": "shashank-reddy-nr", "review_state": null, + "root_timestamp": "2026-07-14T11:35:35Z", "body": "Moving to draft until v1.44 is released.", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -5112,17 +5305,18 @@ "requester": "rajkumar-rangaraj", "pr_author": "martincostello", "review_state": null, + "root_timestamp": "2026-07-28T18:56:55Z", "body": "How much performance impact does adding the IsEventFullNameValid check introduce? \r\nIs there a customer ask for this check?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5139,17 +5333,18 @@ "requester": "laurit", "pr_author": "jhalliday", "review_state": null, + "root_timestamp": "2025-10-10T16:07:13Z", "body": "> The JFR consumer API is 9+ only\r\n\r\nThat isn't completely true. Openjdk contains jfr apis backported from 11 since 8u262. It is a bit weird in the sense that the oracle jdk doesn't contain the backported apis but rather an older version of the jfr api. So actually you don't need to set the java version to 11. One way to make it build would be to use.\r\n\r\n```\r\ntasks {\r\n compileJava {\r\n sourceCompatibility = \"1.8\"\r\n targetCompatibility = \"1.8\"\r\n options.release.set(null as Int?)\r\n }\r\n}\r\n```\r\n\r\nThe issue you have happens because gradle is smart and prevents you adding a dependency that works only with 11 to code that should work with 8. You can disable it with\r\n\r\n```\r\njava {\r\n disableAutoTargetJvm()\r\n}\r\n```", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5166,17 +5361,18 @@ "requester": "laurit", "pr_author": "jhalliday", "review_state": null, + "root_timestamp": "2025-10-13T12:50:18Z", "body": "> @laurit hmm, interesting plot twist there, thanks! That almost but not quite works - the compiler is happy, but animal sniffer is not. I assume it's either no longer sure what version it's supposed to be testing against, or thinks jfr isn't in 8.\r\n\r\nanimal sniffer checks run agains apis supported by android, see https://github.com/open-telemetry/opentelemetry-java/blob/da295cfa3c93b73376e4c32f2dd450b2035483b3/animal-sniffer-signature/build.gradle.kts#L27-L28 I doubt that these will pass no matter what java version you use for compiling. You will probably have to disable animal sniffer (could remove https://github.com/open-telemetry/opentelemetry-java/blob/da295cfa3c93b73376e4c32f2dd450b2035483b3/exporters/otlp/profiles/build.gradle.kts#L6) for the module if you wish to use jfr or move jfr code into separate module or maybe a separate source set would also be enough to trick it (see https://github.com/open-telemetry/opentelemetry-java/blob/da295cfa3c93b73376e4c32f2dd450b2035483b3/buildSrc/src/main/kotlin/otel.animalsniffer-conventions.gradle.kts#L14)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5193,17 +5389,18 @@ "requester": "marschall", "pr_author": "jhalliday", "review_state": null, + "root_timestamp": "2026-04-02T20:28:20Z", "body": "This may do what you need https://github.com/marschall/jfr-opentelemetry-bridge. Let me know what you think.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5220,17 +5417,18 @@ "requester": "jack-berg", "pr_author": "brunobat", "review_state": null, + "root_timestamp": "2025-10-28T19:31:56Z", "body": "> This prevents the instantiation of Senders outside of the SDK.\r\n\r\nWhy?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5241,23 +5439,52 @@ ] }, { - "id": "pr-issue-comment-4347488931", + "id": "pr-review-3816729609", "repo": "opentelemetry-java", "pull_request": 8076, "requester": "jack-berg", "pr_author": "jackshirazi", - "review_state": null, - "body": "> Also there is the issue of replacing a single value vs replacing a node subtree. It looks like I need two new APIs for that\r\n\r\nI agree you'll need APIs for that. Should probably be at the SDK level though (SdkConfigProvider) rather than API (ConfigProvider). API is accessible to instrumentation and we want instrumentation to be consuming config, not mucking around and editing it, right?", + "review_state": "COMMENTED", + "root_timestamp": "2026-02-17T22:59:36Z", + "body": "These contracts look like a good start to me. Missing implementation corresponding spec though so need to talk about how to proceed with that.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-issue-comment-4347488931", + "repo": "opentelemetry-java", + "pull_request": 8076, + "requester": "jack-berg", + "pr_author": "jackshirazi", + "review_state": null, + "root_timestamp": "2026-04-29T21:01:49Z", + "body": "> Also there is the issue of replacing a single value vs replacing a node subtree. It looks like I need two new APIs for that\r\n\r\nI agree you'll need APIs for that. Should probably be at the SDK level though (SdkConfigProvider) rather than API (ConfigProvider). API is accessible to instrumentation and we want instrumentation to be consuming config, not mucking around and editing it, right?", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5274,24 +5501,25 @@ "requester": "jack-berg", "pr_author": "jackshirazi", "review_state": null, + "root_timestamp": "2026-04-30T21:31:50Z", "body": "> preference? or alternative?\r\n\r\nI've sketched out a few ideas in: https://github.com/jackshirazi/opentelemetry-java/pull/1\r\n\r\nEasier to talk in code these days. \r\n\r\nMost notably:\r\n\r\n- The update API is SDK only\r\n- The update APIs are consolidated into a single `setConfig(String path, Object value)` method\r\n- Verification that when an update occurs, the update target path is either unset or that the type of the existing value matches the new value\r\n- The CAS loop notification path is simplified by just using a lock - in the process, this fixes a race condition where a listener could be notified of update _after_ a _later_ update. I.e. given update 1 at T1, update 2 at T2, listener receives update 2 then update 1, and is permanently left with out of date state", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", "author_action", - "no_author_action" + "author_action" ] }, { @@ -5301,21 +5529,22 @@ "requester": "jack-berg", "pr_author": "jackshirazi", "review_state": null, + "root_timestamp": "2026-06-09T19:03:15Z", "body": "Sorry for the delay. Missed that you had replied to this.\r\n\r\n> My concern with this implementation is how do I call the setConfig from an extension? GlobalOpenTelemetry.get() is returned as an obfuscated wrapper, so can't be cast to ExtendedOpenTelemetrySdk\r\n\r\nI assume you mean agent extension. Agent extensions get access to `OpenTelemetrySdk` and so would have access to ExtendedOpenTelemetrySdk.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "no_author_action", + "author_action", "no_author_action", "no_author_action", "no_author_action" @@ -5328,44 +5557,18 @@ "requester": "jack-berg", "pr_author": "jackshirazi", "review_state": null, + "root_timestamp": "2026-06-09T19:27:20Z", "body": "I like the code here and would be happy to approve / merge it once corresponding spec is available 👍", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-3816729609", - "repo": "opentelemetry-java", - "pull_request": 8076, - "requester": "jack-berg", - "pr_author": "jackshirazi", - "review_state": "COMMENTED", - "body": "These contracts look like a good start to me. Missing implementation corresponding spec though so need to talk about how to proceed with that.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -5376,50 +5579,52 @@ ] }, { - "id": "pr-issue-comment-4047703314", + "id": "pr-review-3932325269", "repo": "opentelemetry-java", "pull_request": 8164, "requester": "jack-berg", "pr_author": "lucacavenaghi97", - "review_state": null, - "body": "> One thing: now that pretty print isn't on by default, there's no public API for users to actually enable it. The capability only lives on the internal builders\r\n\r\nI think you're referring to the fact that `OtlpStdoutSpanExporter` and `OtlpStdoutSpanExporterBuilder` live in internal packages. In this context, internal indicates that they're still in development and APIs are subject to breaking changes, but users willing to accept that can use:\r\n\r\n```\r\nOtlpStdoutSpanExporter.builder()\r\n .setPrettyPrint(true)\r\n .build();\r\n```\r\n\r\nAs you note, we could add a parameter to `OtlpJsonLoggingSpanExporter#create` to allow this to be configured.\r\n\r\n`OtlpStdoutSpanExporter` is supposed to be the replacement for `OtlpJsonLoggingSpanExporter`, but is still in an internal package because we're waiting for the [corresponding spec document](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/file-exporter.md) to stabilize. \r\n\r\n> Add it as a field in the declarative configuration via the ComponentProvider classes\r\n\r\nI support this.", + "review_state": "COMMENTED", + "root_timestamp": "2026-03-11T20:20:44Z", + "body": "Couple comments but I like the direction", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", + "no_author_action", + "no_author_action", "no_author_action", "no_author_action", "no_author_action" ] }, { - "id": "pr-review-3932325269", + "id": "pr-issue-comment-4047703314", "repo": "opentelemetry-java", "pull_request": 8164, "requester": "jack-berg", "pr_author": "lucacavenaghi97", - "review_state": "COMMENTED", - "body": "Couple comments but I like the direction", + "review_state": null, + "root_timestamp": "2026-03-12T15:30:01Z", + "body": "> One thing: now that pretty print isn't on by default, there's no public API for users to actually enable it. The capability only lives on the internal builders\r\n\r\nI think you're referring to the fact that `OtlpStdoutSpanExporter` and `OtlpStdoutSpanExporterBuilder` live in internal packages. In this context, internal indicates that they're still in development and APIs are subject to breaking changes, but users willing to accept that can use:\r\n\r\n```\r\nOtlpStdoutSpanExporter.builder()\r\n .setPrettyPrint(true)\r\n .build();\r\n```\r\n\r\nAs you note, we could add a parameter to `OtlpJsonLoggingSpanExporter#create` to allow this to be configured.\r\n\r\n`OtlpStdoutSpanExporter` is supposed to be the replacement for `OtlpJsonLoggingSpanExporter`, but is still in an internal package because we're waiting for the [corresponding spec document](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/file-exporter.md) to stabilize. \r\n\r\n> Add it as a field in the declarative configuration via the ComponentProvider classes\r\n\r\nI support this.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -5430,57 +5635,59 @@ ] }, { - "id": "pr-issue-comment-4179084645", + "id": "pr-review-3963617049", "repo": "opentelemetry-java", "pull_request": 8197, "requester": "jack-berg", "pr_author": "sridharsurvi1", - "review_state": null, - "body": "Sorry for the delay - went on vacation and lost track of this. \r\n\r\n> A load balancer is a heavyweight solution when the actual need is simple: \"if this endpoint is down, try that one.\" The SDK already has the context to make this decision at export time.\r\n\r\nYou could write a delegating exporter, which accepts multiple OTLP exporters as constructor parameters and calls the second if the first fails. The OTLP exporter's CompletableResultCodes return all the information you would need for a caller to determine why the first export failed and if it should try the second or abandon: https://github.com/open-telemetry/opentelemetry-java/blob/47c970d6c2ebc145f44612d7f04005c855939f3f/exporters/common/src/main/java/io/opentelemetry/exporter/internal/http/HttpExporter.java#L111-L126\r\n\r\n> Would you be open to keeping this PR as a reference implementation while the spec discussion happens? \r\n\r\nSure no problem", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-03-17T20:34:43Z", + "body": "The behavior of our OTLP exporters and corresponding environment variables is dictated by the spec: https://github.com/open-telemetry/opentelemetry-java/blob/main/CONTRIBUTING.md#project-scope\n\nWe have some examples of java specific programmatic configuration options, like the ability to set the executor service and proxy options. But these accommodate well established configuration expectations of network clients. I.e. the absence of options would be a glaring deficiency in the API.\n\nThis fallback endpoint is more complicated and more controversial, and so I would like to see it go through the spec before we consider adding it in opentelemetry-java. \n\nPersonally, wearing my other hat as a spec contributor, I would expect this problem to be solved through load balancing and retry against a single endpoint. I.e. a single endpoint routes to multiple backing instances. If an attempt against the first fails, it does so in a way that triggers the retry policy to execute a subsequent request, which has the opportunity to resolve a different instance.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "author", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", "author_action", "author_action", - "no_author_action" + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-3963617049", + "id": "pr-issue-comment-4179084645", "repo": "opentelemetry-java", "pull_request": 8197, "requester": "jack-berg", "pr_author": "sridharsurvi1", - "review_state": "CHANGES_REQUESTED", - "body": "The behavior of our OTLP exporters and corresponding environment variables is dictated by the spec: https://github.com/open-telemetry/opentelemetry-java/blob/main/CONTRIBUTING.md#project-scope\n\nWe have some examples of java specific programmatic configuration options, like the ability to set the executor service and proxy options. But these accommodate well established configuration expectations of network clients. I.e. the absence of options would be a glaring deficiency in the API.\n\nThis fallback endpoint is more complicated and more controversial, and so I would like to see it go through the spec before we consider adding it in opentelemetry-java. \n\nPersonally, wearing my other hat as a spec contributor, I would expect this problem to be solved through load balancing and retry against a single endpoint. I.e. a single endpoint routes to multiple backing instances. If an attempt against the first fails, it does so in a way that triggers the retry policy to execute a subsequent request, which has the opportunity to resolve a different instance.", + "review_state": null, + "root_timestamp": "2026-04-02T16:38:39Z", + "body": "Sorry for the delay - went on vacation and lost track of this. \r\n\r\n> A load balancer is a heavyweight solution when the actual need is simple: \"if this endpoint is down, try that one.\" The SDK already has the context to make this decision at export time.\r\n\r\nYou could write a delegating exporter, which accepts multiple OTLP exporters as constructor parameters and calls the second if the first fails. The OTLP exporter's CompletableResultCodes return all the information you would need for a caller to determine why the first export failed and if it should try the second or abandon: https://github.com/open-telemetry/opentelemetry-java/blob/47c970d6c2ebc145f44612d7f04005c855939f3f/exporters/common/src/main/java/io/opentelemetry/exporter/internal/http/HttpExporter.java#L111-L126\r\n\r\n> Would you be open to keeping this PR as a reference implementation while the spec discussion happens? \r\n\r\nSure no problem", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -5490,17 +5697,18 @@ "requester": "zeitlinger", "pr_author": "Khepu", "review_state": null, + "root_timestamp": "2026-04-09T11:11:09Z", "body": "Thanks for the contribution!\r\n\r\nPlease run the bench before/after and add results here - see https://github.com/open-telemetry/opentelemetry-java/pull/8271 on how to do it.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5517,17 +5725,18 @@ "requester": "jack-berg", "pr_author": "Khepu", "review_state": null, + "root_timestamp": "2026-04-22T21:51:09Z", "body": "Which ones did you try? Benchmarks collect dust and eventually get out of date, especially the ones not regularly used. Would [RecordSpanBenchmark](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/all/src/jmh/java/io/opentelemetry/sdk/SpanRecordBenchmark.java) show the changes? That's one of the few that we run on an ongoing basis and publish results to https://open-telemetry.github.io/opentelemetry-java/benchmarks/", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5544,17 +5753,18 @@ "requester": "zeitlinger", "pr_author": "jhalliday", "review_state": "COMMENTED", + "root_timestamp": "2026-05-20T07:52:15Z", "body": "Nice metadata additions. Two suggestions:\n\n**Hoist hot-loop dictionary lookups.** In `JfrExecutionSampleEventConverter.accept()` the `\"thread.name\"` key index and `KeyValueAndUnitData` are rebuilt for every sample event. Same in `JfrLocationDataCompositor.frameToLocation()` for `\"profile.frame.type\"`/`\"jvm\"` per frame. The dict dedupes so output is correct, but each call still allocates a string + `KeyValueAndUnitData`. Since the key/value pair is constant per converter, compute it once (e.g. in the constructor or lazily cached) and reuse the int index.\n\nFor the thread sample, only `threadName`/`threadNameData` vary — pre-compute the `\"thread.name\"` key index once.\n\n**Null `sampledThread`.** `recordedEvent.getValue(\"sampledThread\")` can be `null` for some ExecutionSample variants. A null guard (skip or fall back to \"unknown\") would harden the converter against truncated/synthetic events.\n\nLGTM otherwise — the `ValueTypeData` fix and frame-type attribute look right.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5571,17 +5781,18 @@ "requester": "psx95", "pr_author": "ADITYA-CODE-SOURCE", "review_state": null, + "root_timestamp": "2026-05-15T15:13:21Z", "body": "You need to run `spotlessApply` to fix some of the failures.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5598,17 +5809,18 @@ "requester": "jack-berg", "pr_author": "ADITYA-CODE-SOURCE", "review_state": null, + "root_timestamp": "2026-05-18T17:22:30Z", "body": "Hey I want to take a step back on this. This PR represents a precedent that we're going to jump through additional hoops to support groovy.\r\n\r\nWe don't say anything about groovy or other JVM based languages in our [versioning policy](https://github.com/open-telemetry/opentelemetry-java/blob/main/VERSIONING.md). And its not that a don't want to support these. But I don't understand what supporting entails. Groovy for example, has different class loading semantics that has runs into issues with the patterns we use to activate different capabilities based on whether or not certain dependencies are present. For example, the metrics, logs, and trace SDKs all behave differently based on whether `opentelemetry-api-incubator` is present, using techniques like [this](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/SdkMeter.java#L54-L63) to detect if the module is present, and helps like [this](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/IncubatingUtil.java) that interact with the standard java classloader in such a way that the incubating classes ar ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5625,98 +5837,46 @@ "requester": "laurit", "pr_author": "ADITYA-CODE-SOURCE", "review_state": null, + "root_timestamp": "2026-05-19T06:10:16Z", "body": "Did you try using `@CompileStatic`? As far as I understand the only relevant change is in the signature of `setConfigProvider`. Is calling `IncubatingUtil` via reflection necessary?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-4962763352", - "repo": "opentelemetry-java", - "pull_request": 8446, - "requester": "jack-berg", - "pr_author": "ADITYA-CODE-SOURCE", - "review_state": null, - "body": "@open-telemetry/java-approvers - heads up - this PR adds a default OTLP message / request body size of 64mb, where none currently exists. You could make the argument that this is a breaking behavior change, and that we should proceed but only once there is a env var / declarative config property to configure a different limit. (Ive opened https://github.com/open-telemetry/opentelemetry-configuration/issues/695 to add declarative config schema to configure this)\r\n\r\nPersonally, I think the lack of current limit is a bug and adding a default of 64mb is a generous limit few will hit.", - "role": "scored", - "stability": "flaky", - "recorded_label": null, - "adjudicated_label": null, - "run_actions": [ - "author", - "none", - "none", - "none", - "none" ], "run_labels": [ "author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-issue-comment-4974615477", + "id": "pr-review-4470200721", "repo": "opentelemetry-java", "pull_request": 8446, - "requester": "jkwatson", + "requester": "jack-berg", "pr_author": "ADITYA-CODE-SOURCE", - "review_state": null, - "body": "I'm fine with the API changes in this PR", + "review_state": "COMMENTED", + "root_timestamp": "2026-06-10T17:53:32Z", + "body": "A few small comments, but looks pretty good! Thanks for working on this!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4470200721", - "repo": "opentelemetry-java", - "pull_request": 8446, - "requester": "jack-berg", - "pr_author": "ADITYA-CODE-SOURCE", - "review_state": "COMMENTED", - "body": "A few small comments, but looks pretty good! Thanks for working on this!", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ "no_author_action", @@ -5733,17 +5893,18 @@ "requester": "jack-berg", "pr_author": "ADITYA-CODE-SOURCE", "review_state": "APPROVED", + "root_timestamp": "2026-06-16T20:15:30Z", "body": "Looks like there are still some build failures from static analysis. \n\nCouple more nits to fix along with the build, but looks good to me", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5754,50 +5915,52 @@ ] }, { - "id": "pr-issue-comment-4961163009", + "id": "pr-issue-comment-4962763352", "repo": "opentelemetry-java", - "pull_request": 8464, + "pull_request": 8446, "requester": "jack-berg", - "pr_author": "jsuereth", + "pr_author": "ADITYA-CODE-SOURCE", "review_state": null, - "body": "PR with my remaining feedback here: https://github.com/jsuereth/opentelemetry-java/pull/1", + "root_timestamp": "2026-07-13T21:16:36Z", + "body": "@open-telemetry/java-approvers - heads up - this PR adds a default OTLP message / request body size of 64mb, where none currently exists. You could make the argument that this is a breaking behavior change, and that we should proceed but only once there is a env var / declarative config property to configure a different limit. (Ive opened https://github.com/open-telemetry/opentelemetry-configuration/issues/695 to add declarative config schema to configure this)\r\n\r\nPersonally, I think the lack of current limit is a bug and adding a default of 64mb is a generous limit few will hit.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "author" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "author_action", "no_author_action", "no_author_action", - "author_action" + "no_author_action" ] }, { - "id": "pr-review-4571515808", + "id": "pr-issue-comment-4974615477", "repo": "opentelemetry-java", - "pull_request": 8464, - "requester": "jack-berg", - "pr_author": "jsuereth", - "review_state": "COMMENTED", - "body": "Looking pretty good", + "pull_request": 8446, + "requester": "jkwatson", + "pr_author": "ADITYA-CODE-SOURCE", + "review_state": null, + "root_timestamp": "2026-07-14T22:32:20Z", + "body": "I'm fine with the API changes in this PR", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -5808,23 +5971,80 @@ ] }, { - "id": "pr-review-4687844736", + "id": "pr-review-4571515808", "repo": "opentelemetry-java", "pull_request": 8464, "requester": "jack-berg", "pr_author": "jsuereth", - "review_state": "APPROVED", - "body": "Looks good from my side. I don't have any preference on \"raw attributes\" vs \"unassociated attributes\" naming. Choose whatever is most likely to pass spec scrutiny, but we can merge here even without spec and update our naming later if needed.\n\nStill need to merge main and fix some minor things.\n\nAlso, should update the PR description to reflect the final state, so its accurate for any future readers.", + "review_state": "COMMENTED", + "root_timestamp": "2026-06-25T14:13:22Z", + "body": "Looking pretty good", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-issue-comment-4961163009", + "repo": "opentelemetry-java", + "pull_request": 8464, + "requester": "jack-berg", + "pr_author": "jsuereth", + "review_state": null, + "root_timestamp": "2026-07-13T18:15:58Z", + "body": "PR with my remaining feedback here: https://github.com/jsuereth/opentelemetry-java/pull/1", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-4687844736", + "repo": "opentelemetry-java", + "pull_request": 8464, + "requester": "jack-berg", + "pr_author": "jsuereth", + "review_state": "APPROVED", + "root_timestamp": "2026-07-13T18:59:10Z", + "body": "Looks good from my side. I don't have any preference on \"raw attributes\" vs \"unassociated attributes\" naming. Choose whatever is most likely to pass spec scrutiny, but we can merge here even without spec and update our naming later if needed.\n\nStill need to merge main and fix some minor things.\n\nAlso, should update the PR description to reflect the final state, so its accurate for any future readers.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5841,17 +6061,18 @@ "requester": "psx95", "pr_author": "ADITYA-CODE-SOURCE", "review_state": null, + "root_timestamp": "2026-06-10T16:50:51Z", "body": "What's the motivation behind this change? Is this related to https://github.com/open-telemetry/opentelemetry-java/issues/8198 ?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5868,17 +6089,18 @@ "requester": "jack-berg", "pr_author": "renovate", "review_state": null, + "root_timestamp": "2026-07-13T21:36:11Z", "body": "Blocked by codeql support:\r\n\r\n> Caused by: com.semmle.extractor.java.interceptors.KotlinInterceptor$KotlinVersionTooRecentError: Kotlin version 2.4.0 is too recent. CodeQL currently supports versions below 2.3.30", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5895,23 +6117,24 @@ "requester": "jkwatson", "pr_author": "renovate", "review_state": null, + "root_timestamp": "2026-07-16T15:28:13Z", "body": "> Blocked by codeql support:\r\n> \r\n> > Caused by: com.semmle.extractor.java.interceptors.KotlinInterceptor$KotlinVersionTooRecentError: Kotlin version 2.4.0 is too recent. CodeQL currently supports versions below 2.3.30\r\n\r\nYeah, codeql is a real problem here. We've been stuck on them being always behind for a while now. Maybe we should reconsider codeql for kotlin if we want to keep up with the kotlin versioning.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "none", - "author" + "author_action", + "no_author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ + "author_action", "no_author_action", "author_action", "author_action", - "no_author_action", "author_action" ] }, @@ -5922,17 +6145,18 @@ "requester": "jack-berg", "pr_author": "EvgeniiR", "review_state": null, + "root_timestamp": "2026-07-01T19:36:52Z", "body": "> This violated the OpenTelemetry specification, which requires that\r\nattribute name alone determines identity — last write wins regardless of type.\r\n\r\nCan you provide a link the portion of the spec you're referring to? Thanks.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5949,17 +6173,18 @@ "requester": "jack-berg", "pr_author": "EvgeniiR", "review_state": null, + "root_timestamp": "2026-07-01T20:27:06Z", "body": "> I'm not sure if you're asking because the PR description doesn't provide enough context, or if you think I might be misinterpreting the spec and solving a problem that doesn't actually exist. Happy to clarify either way.\r\n\r\nThe spec is big and occasionally contradictory. Always good to have a reference!\r\n\r\n> I originally found this through the linked issue. \r\n\r\nMissing the linked issue", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -5976,24 +6201,25 @@ "requester": "jack-berg", "pr_author": "EvgeniiR", "review_state": null, + "root_timestamp": "2026-07-02T21:38:54Z", "body": "Hey so I've been thinking about this. AttributesMap exists because the default implementation of Attributes / AttributesBuilder is not limits aware. I think that the fact that its backed by HashMap is a function of convenience: we need a simple implementation that we can apply limits too as its being built up. I think performance is important, and a Map based implementation also has better put performance than the default array based implementations ImmutableKeyValuePairs / ArrayBackedAttributesBuilder. But I think this is coincidence, since I've never heard us telling people \"prefer using Span.setAttribute because it uses a more performant map based implementation\". \r\n\r\nI've never loved the fact that AttributesMap exists. I'd rather have one implementation. And I think your changes to AttributesMap reinforces this because while it still tries to do some map things for performance, other parts of it are starting to look more like ImmutableKeyValuePairs / ArrayBackedAttributesBuilder. And so its got me thinking about whether we can evolve ImmutableKeyValuePairs / ArrayBackedAttributesBuilder to meet the limits requirements and rip out AttributesMap altogether.\r\n\r\nI've got two protot ...[truncated]", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "author", - "none" + "no_author_action", + "no_author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", "no_author_action", "no_author_action", "author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -6003,17 +6229,18 @@ "requester": "jack-berg", "pr_author": "EvgeniiR", "review_state": null, + "root_timestamp": "2026-07-02T21:39:15Z", "body": "@open-telemetry/java-approvers PTAL at my message above and let me know if you have thoughts.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6030,17 +6257,18 @@ "requester": "jkwatson", "pr_author": "EvgeniiR", "review_state": null, + "root_timestamp": "2026-07-10T16:04:03Z", "body": "I would love to get us to a single implementation as well. The de-duping logic in the array based approach has always been the scary bit to my avoiding use using it instead of AttributesMap. If we're ok eating that performance hit, option 3 seems fine to me (as does 2, tbh). it's all the usual tradeoff of memory vs. speed, slightly coupled with maintenance complexity, I suppose (it's more maintenance to have 2 implementations vs. just 1). \r\n\r\nI wonder if there's a clever solution to the deduping, using some sort of lightweight sketch-based approach, alongside the array to save the linear scan in most cases. Could be an interesting research project for someone with time on their hands. ;)", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6057,17 +6285,18 @@ "requester": "trask", "pr_author": "opentelemetrybot", "review_state": null, + "root_timestamp": "2026-07-21T04:37:06Z", "body": "cc @trask to review first", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6084,24 +6313,25 @@ "requester": "trask", "pr_author": "opentelemetrybot", "review_state": "APPROVED", + "root_timestamp": "2026-07-22T18:23:11Z", "body": "LGTM, but you could wait until we merge similar in other Java repos and go through release to verify", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", "no_author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -6111,17 +6341,18 @@ "requester": "jack-berg", "pr_author": "adhamahmad", "review_state": null, + "root_timestamp": "2026-07-16T20:19:08Z", "body": "Hey I gave this issue some thought and shared my analysis here: https://github.com/open-telemetry/opentelemetry-java/issues/7573#issuecomment-4996197430\r\n\r\nI think we should go in a different direction with this: #8610, which embodies option d in the comment.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6138,17 +6369,18 @@ "requester": "adhamahmad", "pr_author": "jack-berg", "review_state": null, + "root_timestamp": "2026-07-17T01:25:12Z", "body": "Hey @jack-berg, thanks for the detailed analysis. \r\n\r\nI had one question about test coverage: is there a test that verifies the actual motivating scenario from #7573 — successfully reaching a real TLSv1/TLSv1.1-only server with enabledProtocols set and the JVM floor opened?\r\n\r\nAs written, `enabledProtocols()` only exercises TLS 1.2/1.3 against a TLS 1.2/1.3 server, which would still pass if `setEnabledProtocols()` were a no-op since that is already the default range.\r\nI don't see a test covering the full \"both gates open\" scenario against a legacy server, which was the original bug report.\r\n\r\nI ran into a related issue testing this in my [PR](https://github.com/open-telemetry/opentelemetry-java/pull/8599):` jdk.tls.disabledAlgorithms` behavior is JVM-wide, and changing it at runtime can be problematic once TLS initialization has already happened. That made a legacy-server test order-dependent in practice. \r\nIf that is why this scenario was intentionally omitted, that makes sense as a stability tradeoff.\r\n\r\nI just wanted to confirm whether that was the reasoning, or if I missed an existing test covering it.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6165,17 +6397,18 @@ "requester": "jack-berg", "pr_author": "ADITYA-CODE-SOURCE", "review_state": "COMMENTED", + "root_timestamp": "2026-07-27T21:07:56Z", "body": "Just a couple more minor comments. Looks pretty good!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6192,17 +6425,18 @@ "requester": "trask", "pr_author": "onurkybsi", "review_state": "COMMENTED", + "root_timestamp": "2026-04-20T01:58:58Z", "body": "Purely AI generated review below\n\n---------------------------\n\nReview of the Failsafe 3.0 javaagent instrumentation + testing module extraction. A few correctness/style issues worth addressing:\n\n- **javaagent advice**: `@Advice.OnMethodExit` has `onThrowable = Throwable.class` but the body is return-only (it casts `@Advice.Return` and derives values from it). On the exceptional path the return is `null` and the cast triggers a (suppressed) exception for no benefit — drop `onThrowable`.\n- **Default policy name in javaagent mode**: `impl.toString()` is used as the retry-policy name, which will produce uninformative values like `dev.failsafe.internal.RetryPolicyImpl@2f4d3e5a` as the `failsafe.retry_policy.name` attribute. Worth considering a cleaner fallback (e.g., the implementation class simple name, or just leaving the attribute out when no user-supplied name exists).\n- **Reflection-based mutation of `PolicyConfig`**: writing to private `failureListener`/`successListener` fields is brittle and muzzle cannot protect against these fields being renamed/removed in a future Failsafe version. Worth noting in a comment and/or considering a `fail` muzzle block or explicit guard.\n- **Style ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6219,17 +6453,18 @@ "requester": "trask", "pr_author": "steverao", "review_state": null, + "root_timestamp": "2026-03-19T02:05:25Z", "body": "@steverao thanks for the detailed explanation! I think that's ok, not sure any way around it, just update the testLatestDeps test to reflect the reality of the disconnected trace.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6239,6 +6474,34 @@ "author_action" ] }, + { + "id": "pr-review-4396510761", + "repo": "opentelemetry-java-instrumentation", + "pull_request": 18844, + "requester": "singhvibhanshu", + "pr_author": "amit306", + "review_state": "APPROVED", + "root_timestamp": "2026-05-31T07:12:17Z", + "body": "LGTM, just a nit:\n\nhttps://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/4c57afb6c7460b05eda858114d74ad8da4794973/instrumentation/spring/spring-webflux/spring-webflux-5.3/library/README.md?plain=1#L81\n\nSuggested change: `return webfluxServerTelemetry.createWebFilter();`", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, { "id": "pr-issue-comment-4590393251", "repo": "opentelemetry-java-instrumentation", @@ -6246,17 +6509,18 @@ "requester": "singhvibhanshu", "pr_author": "amit306", "review_state": null, + "root_timestamp": "2026-06-01T07:22:40Z", "body": "May I ask for a review from @open-telemetry/java-instrumentation-approvers when any of them get a chance?\r\n\r\nThanks!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6273,17 +6537,18 @@ "requester": "laurit", "pr_author": "amit306", "review_state": null, + "root_timestamp": "2026-06-02T11:56:03Z", "body": "https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/17858 asks whether the reactor hook should be always registered. Did you attempt to fina an answer to that question? What are the benefits of registering the reactor hook? What would we loose if we did it the other way around and never registered it in these methods?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6300,51 +6565,25 @@ "requester": "singhvibhanshu", "pr_author": "amit306", "review_state": null, + "root_timestamp": "2026-07-08T17:01:44Z", "body": "@laurit,\r\nIt's been a while, may we get your review here?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4396510761", - "repo": "opentelemetry-java-instrumentation", - "pull_request": 18844, - "requester": "singhvibhanshu", - "pr_author": "amit306", - "review_state": "APPROVED", - "body": "LGTM, just a nit:\n\nhttps://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/4c57afb6c7460b05eda858114d74ad8da4794973/instrumentation/spring/spring-webflux/spring-webflux-5.3/library/README.md?plain=1#L81\n\nSuggested change: `return webfluxServerTelemetry.createWebFilter();`", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -6354,17 +6593,18 @@ "requester": "laurit", "pr_author": "philsttr", "review_state": null, + "root_timestamp": "2026-06-09T13:58:51Z", "body": "Is there prior art for this in otel ecosystem? There is a [moratorium](https://github.com/open-telemetry/opentelemetry-specification/issues/2891#issuecomment-1289241503) in otel spec for introducing new environment variables with complex encoding. The moratorium was originally in place to incentivize development of declarative config, which is done now. While we are not strictly bound by this moratorium the question is still whether there could be a better solution for this that does not involve complex encodings. Perhaps some sort of include/exclude pair would work better?\r\ncc @trask", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6381,17 +6621,18 @@ "requester": "trask", "pr_author": "philsttr", "review_state": null, + "root_timestamp": "2026-06-12T03:28:58Z", "body": "check out declarative config and the pattern for includes/excludes: \r\n\r\n- https://github.com/open-telemetry/opentelemetry-configuration\r\n- https://github.com/open-telemetry/opentelemetry-configuration/blob/main/CONTRIBUTING.md#properties-requiring-pattern-matching\r\n- https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/common/src/main/java/io/opentelemetry/sdk/common/internal/IncludeExcludePredicate.java", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6408,24 +6649,25 @@ "requester": "trask", "pr_author": "philsttr", "review_state": null, + "root_timestamp": "2026-07-14T21:48:10Z", "body": "> Is it true that opentelemetry-sdk-common (and therefore `IncludeExcludePredicate`) cannot be used by instrumentations?\r\n\r\noh yeah, instrumentation should only rely on OpenTelemetry API and not on the SDK\r\n\r\nI pushed a commit to copy in those classes, let's give that a try", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", "no_author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -6435,17 +6677,18 @@ "requester": "trask", "pr_author": "zeitlinger", "review_state": null, + "root_timestamp": "2026-07-08T21:22:12Z", "body": "Can you do some analysis on what (quantitative) benefits this has, so we can weigh the risks? thanks", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6462,17 +6705,18 @@ "requester": "trask", "pr_author": "somiljain2006", "review_state": null, + "root_timestamp": "2026-07-13T20:32:18Z", "body": "thanks @somiljain2006!\r\n\r\nI'm wondering if this is needed, I think same can be accomplished via Metric Views, e.g.\r\n\r\n```\r\nmeter_provider:\r\n views:\r\n - selector:\r\n meter_name: io.opentelemetry.micrometer-1.5\r\n instrument_name: jvm.*\r\n stream:\r\n aggregation:\r\n drop: {}\r\n - selector:\r\n meter_name: io.opentelemetry.micrometer-1.5\r\n instrument_name: process.cpu.usage\r\n stream:\r\n aggregation:\r\n drop: {}\r\n```\r\n\r\ncc @SylvainJuge who opened the linked issue", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6489,24 +6733,25 @@ "requester": "SylvainJuge", "pr_author": "somiljain2006", "review_state": null, + "root_timestamp": "2026-07-15T09:52:28Z", "body": "> thanks @somiljain2006!\r\n> \r\n> I'm wondering if this is needed, I think same can be accomplished via Metric Views, e.g.\r\n> \r\n> ```\r\n> meter_provider:\r\n> views:\r\n> - selector:\r\n> meter_name: io.opentelemetry.micrometer-1.5\r\n> instrument_name: jvm.*\r\n> stream:\r\n> aggregation:\r\n> drop: {}\r\n> - selector:\r\n> meter_name: io.opentelemetry.micrometer-1.5\r\n> instrument_name: process.cpu.usage\r\n> stream:\r\n> aggregation:\r\n> drop: {}\r\n> ```\r\n> \r\n> cc @SylvainJuge who opened the linked issue\r\n\r\nI think this should solve the \"opt-out\" strategy described in the issue, however I don't think this very practical, in particular when conflicts are now known in advance.\r\n\r\nSee also related [slack discussion](https://cloud-native.slack.com/archives/C014L2KCTE3/p1783586947945979) where a few other options are being discussed.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", + "author_action" + ], + "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -6516,17 +6761,18 @@ "requester": "laurit", "pr_author": "YaoYingLong", "review_state": "COMMENTED", + "root_timestamp": "2026-07-03T07:56:12Z", "body": "Library instrumentation should have a readme with instructions on how to set it up. Since this instrumentation produces metrics without semantic conventions it might be best to also list these in the readme, maybe add a table with the metric names and descriptions (and units?) similarly to what runtime-telemetry library module has.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6543,24 +6789,25 @@ "requester": "laurit", "pr_author": "maryantocinn", "review_state": null, + "root_timestamp": "2026-07-02T09:00:38Z", "body": "I think we should add these for all messaging instrumentation (doing just kafka in this PR is fine, the rest can be handled separately). It is not ideal that we only have `messaging.receive.duration` and `messaging.publish.duration` but nothing for `process`. I think we have the following choices\r\n- leave it as is, don't add anything for `process`\r\n- add the missing `process` metrics based on https://github.com/open-telemetry/semantic-conventions/blob/v1.24.0/docs/messaging/messaging-metrics.md (there the metric names contains `deliver` instead of `process`)\r\n- switch to metrics from current semconv https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/messaging-metrics.md Since our messaging implementation doesn't really follow any version of the semantic conventions this might not be that bad. Since the messaging metrics are currently only implemented for pulsar the backwards compatibility concerns are limited.\r\n\r\n@trask do you have any preference on how we should handle this?", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", + "author_action" + ], + "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -6570,23 +6817,24 @@ "requester": "trask", "pr_author": "maryantocinn", "review_state": null, + "root_timestamp": "2026-07-14T21:30:36Z", "body": "> @trask do you have any preference on how we should handle this?\r\n\r\nIt has downsides, but I'd lean towards continuing to follow https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/README.md, which basically says, emit the old semconv by default, and only emit new semconv under `OTEL_SEMCONV_STABILITY_OPT_IN` (and in our case starting with 3.0, `OTEL_SEMCONV_STABILITY_PREVIEW`).\r\n\r\nWe could bump to latest (even before stable), but ideally only after we have implemented the same conventions consistently across all of our messaging instrumentations. It would probably be confusing for some of our messaging instrumentations to emit earlier semconv and some later semconv by default.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", + "author_action", "no_author_action" ] }, @@ -6597,22 +6845,23 @@ "requester": "laurit", "pr_author": "maryantocinn", "review_state": null, + "root_timestamp": "2026-07-15T14:24:27Z", "body": "> It has downsides, but I'd lean towards continuing to follow https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/README.md, which basically says, emit the old semconv by default, and only emit new semconv under `OTEL_SEMCONV_STABILITY_OPT_IN` (and in our case starting with 3.0, `OTEL_SEMCONV_STABILITY_PREVIEW`).\r\n> \r\n> We could bump to latest (even before stable), but ideally only after we have implemented the same conventions consistently across all of our messaging instrumentations. It would probably be confusing for some of our messaging instrumentations to emit earlier semconv and some later semconv by default.\r\n\r\nThe thing is that our messaging semconv don't really follow a particular version of the semconv. The version that is closest to how we emit spans doesn't define metrics at all. The messaging metrics are currently only enabled for pulsar so I'd say we can probably allow incompatible changes if we so desire since their usage is limited.\r\n@trask do I understand correctly that your preference is to use https://github.com/open-telemetry/semantic-conventions/blob/v1.25.0/docs/messaging/messaging-metrics.md for metrics (1.24.0 has `deliver` inste ...[truncated]", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", + "no_author_action" + ], + "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", "no_author_action" ] @@ -6624,24 +6873,25 @@ "requester": "trask", "pr_author": "maryantocinn", "review_state": null, + "root_timestamp": "2026-07-16T04:30:24Z", "body": "> The thing is that our messaging semconv don't really follow a particular version of the semconv.\r\n\r\nYou've convinced me 😅.\r\n\r\nBut if we're going to do it, let's take the opportunity to sync them all up for 3.0:\r\n\r\nhttps://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/19233", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", "author_action", "author_action", "author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -6651,17 +6901,18 @@ "requester": "laurit", "pr_author": "angad-2", "review_state": "COMMENTED", + "root_timestamp": "2026-07-07T07:17:01Z", "body": "@jaydeluca with this PR quartz instrumentation will emit an event in case you wish to add this to the collected metadata", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6678,17 +6929,18 @@ "requester": "laurit", "pr_author": "angad-2", "review_state": "APPROVED", + "root_timestamp": "2026-07-07T07:21:38Z", "body": "Open question is whether emitting the event should be configurable or whether there is any reason why it shouldn't be emitted by default.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6705,17 +6957,18 @@ "requester": "trask", "pr_author": "amirdeljouyi", "review_state": null, + "root_timestamp": "2026-07-11T18:35:50Z", "body": "is there a specific reason you had in mind for adding these particular tests? thanks", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6732,25 +6985,167 @@ "requester": "laurit", "pr_author": "amccague", "review_state": null, + "root_timestamp": "2026-07-13T09:37:39Z", "body": "From what I understand the goal of this PR is to provide a way to enhance the span create by http client instrumentation. The problem is that in user code you can't usually easily observe the http client span so you could add attributes to it. When using library instrumentation you could add an attribute extractor with https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/e49a4a9cb1261eaa22af9849786f036a63288e81/instrumentation/ktor/ktor-common-2.0/library/src/main/kotlin/io/opentelemetry/instrumentation/ktor/common/v2_0/AbstractKtorClientTelemetryBuilder.kt#L68 It is mentioned that you could use `currentCoroutineContext().getOpenTelemetryContext()` but this feels more like a coincidence, typically for callbacks our instrumentations expose the parent context of the http client span not the http client span itself. This issue isn't really specific to ktor http client instrumentation, but rather affects all instrumentations that create client or producer spans. It does come up once in a while. I tried solving it with https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/6191 but it didn't get enough traction. There were some concerns that it mi ...[truncated]", - "role": "context", - "stability": null, - "recorded_label": null, + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - null, - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4660197614", + "repo": "opentelemetry-java-instrumentation", + "pull_request": 19152, + "requester": "copilot-pull-request-reviewer[bot]", + "pr_author": "YaoYingLong", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-09T05:54:28Z", + "body": "## Pull request overview\n\nThis PR adds a new `redisson-metrics-2.3` javaagent instrumentation module that emits database connection pool metrics (used/idle connections, min/max pool sizes, and pending requests) for Redisson versions `[2.3.0, 3.18.0)`. It fills a gap in the existing Redisson instrumentation (which only provides client spans/metrics for 3.0+) by instrumenting the internal `ClientConnectionsEntry` construction and `RedisClient.shutdownAsync()` lifecycle, mirroring the established connection-pool-metrics pattern used by the c3p0 and Tomcat JDBC modules.\n\n**Changes:**\n- New instrumentation module instruments the 7-arg `ClientConnectionsEntry` constructor to register `DbConnectionPoolMetrics` and `RedisClient.shutdownAsync()` to unregister them.\n- Reads pool counters via reflection through `AsyncSemaphoreAccessor`, supporting both the legacy `AtomicInteger` and newer `AsyncSemaphore` free-connection counters, with pending-requests support only when an `AsyncSemaphore` is present.\n- Adds Testcontainers-based coverage (default 2.3.0 and latest 3.17.x), plus build/config/docs wiring (settings, FOSSA, CI instrumentation list, latest-dep pin, supported-libraries doc).\n\n### Re ...[truncated]", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", "no_author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", "no_author_action", "author_action", "author_action" ] }, + { + "id": "pr-review-4801208565", + "repo": "opentelemetry-java-instrumentation", + "pull_request": 19152, + "requester": "copilot-pull-request-reviewer[bot]", + "pr_author": "YaoYingLong", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T19:41:03Z", + "body": "## Pull request overview\n\nCopilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.\n\n\n\n\n
\nComments suppressed due to low confidence (2)\n\n**instrumentation/redisson/redisson-metrics-2.3/javaagent/src/test/java/io/opentelemetry/javaagent/instrumentation/redissonmetrics/v2_3/RedissonConnectionPoolMetricsTest.java:144**\n* [Testing] Use the exact attribute assertion here. `hasAttributesSatisfying(...)` silently accepts unexpected attributes, so this test would not catch extra dimensions on the used point.\n```\n .hasAttributesSatisfying(\n```\n**instrumentation/redisson/redisson-metrics-2.3/javaagent/src/test/java/io/opentelemetry/javaagent/instrumentation/redissonmetrics/v2_3/RedissonConnectionPoolMetricsTest.java:138**\n* [Testing] Use the exact attribute assertion here. `hasAttributesSatisfying(...)` silently accepts unexpected attributes, so this test would not catch extra dimensions on the idle point.\n\nThis issue also appears on line 144 of the same file.\n```\n .hasAttributesSatisfying(\n```\n
", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4811760271", + "repo": "opentelemetry-java-instrumentation", + "pull_request": 19152, + "requester": "trask", + "pr_author": "YaoYingLong", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-29T18:41:23Z", + "body": "AI-generated review", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": "no_author_action", + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-4825827430", + "repo": "opentelemetry-java-instrumentation", + "pull_request": 19152, + "requester": "copilot-pull-request-reviewer[bot]", + "pr_author": "YaoYingLong", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-31T05:50:30Z", + "body": "## Pull request overview\n\nCopilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-4830006514", + "repo": "opentelemetry-java-instrumentation", + "pull_request": 19152, + "requester": "trask", + "pr_author": "YaoYingLong", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-31T16:13:11Z", + "body": "Lightly filtered AI-generated feedback — push back freely", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-4938178545", "repo": "opentelemetry-java-instrumentation", @@ -6758,17 +7153,18 @@ "requester": "trask", "pr_author": "YaoYingLong", "review_state": null, + "root_timestamp": "2026-07-10T18:06:45Z", "body": "can you update PR description to include motivation for why this PR? e.g.\r\n\r\n> Decouple Apache DBCP 2.0 connection-pool metrics from JMX registration. The javaagent currently detects the datasource lifecycle only through `MBeanRegistration` callbacks, so an active `BasicDataSource` produces no metrics unless it is registered with an `MBeanServer`.\r\n>\r\n> Register metrics after successful pool initialization by instrumenting `startPoolMaintenance()`, and unregister them when the datasource is closed. Keep `postDeregister()` cleanup for JMX-managed pools. This also supports datasource restart without requiring JMX.\r\n>\r\n> Preserve meaningful pool names by preferring the configured JMX name, then the registered JMX `ObjectName`, and falling back to a generated `dbcp2-N` name. Add coverage for non-JMX pools and each naming path, and update the instrumentation documentation to reflect that JMX is no longer required.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6785,17 +7181,18 @@ "requester": "trask", "pr_author": "YaoYingLong", "review_state": null, + "root_timestamp": "2026-07-16T15:54:16Z", "body": "is this a breaking change? if so, let's put it behind the v3preview flag and try to get it into v2.30.0", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6812,17 +7209,18 @@ "requester": "trask", "pr_author": "YaoYingLong", "review_state": null, + "root_timestamp": "2026-07-19T22:38:55Z", "body": "> is this a breaking change?\r\n\r\nI think no:\r\n\r\nExisting users on the normal successful JMX path retain the name derived from their registered ObjectName. Non-JMX users previously received no Apache DBCP metrics, so the JDBC-derived or fallback name belongs to newly added telemetry and has no existing name to preserve.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6839,17 +7237,18 @@ "requester": "trask", "pr_author": "amit306", "review_state": null, + "root_timestamp": "2026-07-13T21:49:04Z", "body": "hi @amit306!\r\n\r\nI think the goal of #17858 is more about fixing the API (not just documentation), along the lines of your #18844", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6866,17 +7265,18 @@ "requester": "laurit", "pr_author": "amit306", "review_state": null, + "root_timestamp": "2026-07-14T16:30:27Z", "body": "When I created #17858 I thought that maybe it would make sense to always register the reactor hook. Note that #17858 is phrased as a question so answering no is a valid option. After looking more into it I realized that we don't actually have any tests that fail without the reactor hook so apparently rector hook isn't always required. There is also https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/18932 that hints that perhaps we should rethink our reactor instrumentation. Spring folks have a blog post series that explores different options for reactor context propagation https://spring.io/blog/2023/03/28/context-propagation-with-project-reactor-1-the-basics Because of that I think that for now it might be better to improve our documentation to provide guidance when the user should also register the rector hook and when they could get away without registering one.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6893,17 +7293,18 @@ "requester": "laurit", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-07-14T16:15:03Z", "body": "I'm not sure about this. The intent here is to augment the server span with additional attributes as stated in https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/apache-shenyu-2.4/metadata.yaml While the span from context is probably also the server span, unless someone uses method instrumentation or something like that to create additional span, using `LocalRootSpan` feels more clear. An alternative would be to rethink this instrumentation. Perhaps instead of augmenting the server span it could create a controller span like other framework instrumentations?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6920,17 +7321,18 @@ "requester": "jaydeluca", "pr_author": "YaoYingLong", "review_state": "COMMENTED", + "root_timestamp": "2026-07-21T18:01:36Z", "body": "@trask should there be a corresponding semconv issue for this?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -6947,17 +7349,18 @@ "requester": "pichlermarc", "pr_author": "jsokol805", "review_state": null, + "root_timestamp": "2026-03-18T16:36:11Z", "body": "This is currently blocked on https://github.com/open-telemetry/opentelemetry-js/pull/6356 and similar changes in the other SDKs. We currently see issues where if there's not OTel collector, app shutdowns take significantly longer; this PR here would make that issue worse as it stands now.\r\n\r\nWe still want to merge this once the other PR is in though.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -6974,18 +7377,19 @@ "requester": "raphael-theriault-swi", "pr_author": "overbalance", "review_state": null, + "root_timestamp": "2026-04-06T15:23:35Z", "body": "Will give this a look once back from vacation at the end of april", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], "run_labels": [ "no_author_action", "no_author_action", @@ -7001,23 +7405,24 @@ "requester": "david-luna", "pr_author": "overbalance", "review_state": null, + "root_timestamp": "2026-04-07T08:39:59Z", "body": "hi @overbalance \r\n\r\nwe looked at that PR a couple of weeks ago in the JavaScript SIG. We were wondering if possible to make the migration from Karma to vitest in a follow up PR so this one becomes smaller and easier to review.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", - "author_action", + "no_author_action", "author_action" ] }, @@ -7028,17 +7433,18 @@ "requester": "david-luna", "pr_author": "overbalance", "review_state": null, + "root_timestamp": "2026-06-15T12:59:38Z", "body": "> Compile on Node ^26.3.0 in CI while tests continue to run on the full supported matrix (build-on-26, run-on-matrix); drop npm install -g npm@latest steps where the bundled npm already meets the 11.16.0 floor; build the w3c integration server's dependencies at the repo root\r\n\r\nAs long as we test on all supported versions and compile the same way for publishing I'm okay with this change. WDYT @open-telemetry/javascript-approvers ?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -7055,19 +7461,26 @@ "requester": "david-luna", "pr_author": "overbalance", "review_state": "COMMENTED", + "root_timestamp": "2026-06-15T13:53:48Z", "body": "This looks very good. Just a couple of questions.", - "role": "context", - "stability": null, - "recorded_label": null, + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - null, - null, - null, - null, - null + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], - "run_labels": [] + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] }, { "id": "pr-review-4499141335", @@ -7076,24 +7489,25 @@ "requester": "raphael-theriault-swi", "pr_author": "overbalance", "review_state": "COMMENTED", + "root_timestamp": "2026-06-15T17:21:44Z", "body": "Thank you for the refactor on this, left a few comments. Personally very much in favour of getting this in.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -7103,17 +7517,18 @@ "requester": "raphael-theriault-swi", "pr_author": "overbalance", "review_state": "COMMENTED", + "root_timestamp": "2026-06-16T17:53:17Z", "body": "Everything I could think of has been addressed :)", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -7130,21 +7545,22 @@ "requester": "Dhruv-Garg79", "pr_author": "vitorvasc", "review_state": null, + "root_timestamp": "2026-02-16T14:09:48Z", "body": "@cjihrig @vitorvasc can we please get this merged?", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "no_author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "author_action", + "no_author_action", "author_action", "author_action", "author_action" @@ -7157,22 +7573,23 @@ "requester": "cjihrig", "pr_author": "vitorvasc", "review_state": null, + "root_timestamp": "2026-02-16T15:40:26Z", "body": "@Dhruv-Garg79 this still requires review and approval from a project maintainer.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", + "no_author_action" + ], + "run_labels": [ + "author_action", "no_author_action", + "author_action", "no_author_action", "no_author_action" ] @@ -7184,24 +7601,25 @@ "requester": "pichlermarc", "pr_author": "zakcutner", "review_state": null, + "root_timestamp": "2026-02-12T20:24:52Z", "body": "@zakcutner - my original idea was to provide an interface for people to pass their own transports to the exporters, because different transport implementations are so widely requested.\r\n\r\nMy idea was that people would be able to do something like this, but I ran out of time to work on it:\r\n\r\n```ts\r\nconst exporter = createOtlpExporter({\r\n serializer: ProtobufTraceSerializer,\r\n transport: createMyCustomFetchTransport() // returns a custom IExporterTransport impl\r\n});\r\n```\r\n\r\nthe underlying implementation is already somewhat setup for such a thing, but requires a bit more boilerplate\r\n```ts\r\n\r\nimport { createOtlpNetworkExportDelegate } from '@opentelemetry/otlp-exporter-base';\r\nimport { ProtobufTraceSerializer } from `@opentelemetry/otlp-transformer`;\r\n\r\nconst exporter: SpanExporter = new createOtlpExportDelegate({\r\n options: { /** provide all required options accoding to type**/ },\r\n serializer: ProtobufTraceSerializer, // or JsonTraceSerializer\r\n transport: createMyCustomFetchTransport() /** implement this yourself, a wrapper around your custom fetch, make sure to set the content-type header to what you're sending: `application/x-protobuf` or `application/json` **/\r\n}); /* dele ...[truncated]", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "none", - "author" + "no_author_action", + "author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "author_action", - "author_action", "no_author_action", - "author_action" + "author_action", + "no_author_action" ] }, { @@ -7211,24 +7629,25 @@ "requester": "pichlermarc", "pr_author": "zakcutner", "review_state": null, + "root_timestamp": "2026-02-12T20:31:45Z", "body": "So my recommendation for this feature is:\r\n- decline for now\r\n- use workaround for the time being\r\n- drop `node:http` based exporter transport in July 2026\r\n- add this feature as proposed in this PR to the now streamlined interface where it also works for Node.js\r\n- feature is released alongside SDK 3.0, everybody can use it", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", + "author_action", + "author_action", "no_author_action", + "author_action" + ], + "run_labels": [ "no_author_action", + "author_action", + "author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -7238,17 +7657,18 @@ "requester": "overbalance", "pr_author": "zakcutner", "review_state": null, + "root_timestamp": "2026-03-03T22:48:14Z", "body": "Of course, my comments only apply if js core team approves.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -7265,17 +7685,18 @@ "requester": "dyladan", "pr_author": "ida613", "review_state": null, + "root_timestamp": "2026-03-10T13:46:36Z", "body": "Is this needed only for the JS SDK or for other languages as well? Have other language SDKs already solved this problem?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7292,17 +7713,18 @@ "requester": "dyladan", "pr_author": "CharlieTLe", "review_state": null, + "root_timestamp": "2026-03-20T00:45:33Z", "body": "Please do not rebase or otherwise change history and force push as it breaks the link between conversation threads and the code they're referencing", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7319,23 +7741,24 @@ "requester": "rnavarro", "pr_author": "CharlieTLe", "review_state": null, + "root_timestamp": "2026-06-03T23:02:33Z", "body": "I ran into this gap while wiring exemplar support into my own metrics and traces stack (Grafana Cloud Mimir and Tempo, fed from a Node agent) and found this PR with all of the earlier review feedback already addressed in the later commits. Since it has been sitting with conflicts for a couple of months, I rebased it onto current main to keep it moving: https://github.com/rnavarro/opentelemetry-js/tree/feat/metrics-exemplars-rebased\n\nThe rebase preserves all five of @CharlieTLe's commits unchanged. Conflicts were limited to the two CHANGELOG files (entries moved to the current Unreleased section) and `ExemplarReservoir.ts`, where I kept this PR's non-mutating `collect()` together with the `for...of` conversion that landed on main since. On the rebased branch the `sdk-metrics` suite passes 431 tests and `otlp-transformer` passes 220, lint is clean on the changed files, and I verified end to end that a histogram recorded under a sampled span context serializes an exemplar with the correct traceId and spanId through `JsonMetricsSerializer`.\n\n@CharlieTLe if you want to pull that branch into this PR, it is yours to take. If you are short on time, I am happy to open a successor PR that ke ...[truncated]", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", - "author_action", + "no_author_action", "author_action" ] }, @@ -7346,17 +7769,18 @@ "requester": "maryliag", "pr_author": "trentm", "review_state": "COMMENTED", + "root_timestamp": "2026-03-17T13:32:00Z", "body": "is there any test that would have caught this scenario that can be added here?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7373,17 +7797,18 @@ "requester": "themavik", "pr_author": "trentm", "review_state": "COMMENTED", + "root_timestamp": "2026-03-19T12:20:39Z", "body": "This PR replaces _httpPatched/_httpsPatched booleans with isWrapped() checks to avoid double-wrapping http when loaded by both require and import.\n\nDone well: Using isWrapped from the instrumentation base is the right abstraction—it checks the actual patched state instead of tracking it manually. Removing the state flags simplifies enable/disable and avoids races if modules are loaded concurrently. The instrumentation.disable() in test afterEach ensures clean teardown between tests. License header change to SPDX is a nice consistency fix.\n\nSuggestion: The double-instr test verifies no double instrumentation when http is loaded by both require and import. With isWrapped the second load would skip patching. Consider adding a test that explicitly loads http twice (e.g. via two different import paths) and asserts request/emit are wrapped only once, to guard against future regressions.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7400,17 +7825,18 @@ "requester": "david-luna", "pr_author": "trentm", "review_state": "COMMENTED", + "root_timestamp": "2026-04-29T08:48:42Z", "body": "From the experience I had in browser this is a good solution assuming only this instrumentation is patching the HTTP module. `isWrapped` does not ensure your wrapper is the one applied to the wrapped function.\n\nShould we assume http instrumentation is the only patching htese methods?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7427,24 +7853,25 @@ "requester": "themavik", "pr_author": "andidev", "review_state": "COMMENTED", + "root_timestamp": "2026-03-19T12:20:46Z", "body": "This PR adds maxScale option to ExponentialHistogramAggregation to limit the scale of exponential histograms.\n\nDone well: maxScale threads through cleanly—ExponentialHistogramAggregation, ExponentialHistogramAggregator, and ExponentialHistogramAccumulation all get the parameter with DEFAULT_MAX_SCALE=20 preserving backward compatibility. The mapping ?? getMapping(maxScale) in the accumulation constructor handles the optional mapping param correctly. AggregationOption type and toAggregation wiring are updated. Tests cover default (20), custom maxScale, and multiple accumulations sharing the same maxScale.\n\nMinor: The ExponentialHistogramAccumulation constructor signature changed—mapping is now optional and maxScale is a new positional arg. Any external code that passed mapping explicitly might need to use keyword args. Worth a changelog note if this is a public API.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", + "no_author_action", + "no_author_action", "author_action", + "no_author_action" + ], + "run_labels": [ "author_action", + "no_author_action", + "no_author_action", "author_action", - "author_action" + "no_author_action" ] }, { @@ -7454,17 +7881,18 @@ "requester": "dyladan", "pr_author": "andidev", "review_state": "COMMENTED", + "root_timestamp": "2026-03-23T13:10:55Z", "body": "This looks good to me but I'd like to have someone like @pichlermarc or @legendecas who is a bit closer to the implementation take a look", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -7481,17 +7909,18 @@ "requester": "dyladan", "pr_author": "gunjam", "review_state": null, + "root_timestamp": "2026-03-22T17:18:23Z", "body": "Please do not rebase or otherwise change history as it breaks the link between review comment threads and the code", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7508,17 +7937,18 @@ "requester": "dyladan", "pr_author": "daniellockyer", "review_state": null, + "root_timestamp": "2026-04-01T15:02:23Z", "body": ">I'm not entirely happy about pulling time-related logic outside of _getTime but figure it's worth it given the improvement. Happy to switch to something else if we can maintain the improvement.\r\n\r\nThe span creation benchmark currently shows around `500,000` ops per second which works out to 2 microseconds per operation. Improving that by 10% is only a shave of 200 ns. Is it really worth it?\r\n\r\nEspecially since that benchmark seems to fluctuate by 5-10% on any given run without changes, are you sure you're even getting the expected gains? I've found you need to run the benchmarks several times to get reasonable results. You may want to also consider using the microtime option when running the benchmark in order to make sure you're catching small differences.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7535,23 +7965,24 @@ "requester": "dyladan", "pr_author": "daniellockyer", "review_state": null, + "root_timestamp": "2026-04-01T16:51:05Z", "body": "I was able to achieve a similar speedup by saving the performance start time from the constructor in a class property instead of calling `performance.now` in `_getTime` and combining the `if` statements like so (avoids second branch check):\r\n\r\n```typescript\r\n constructor(opts: SpanOptions) {\r\n const now = Date.now();\r\n this._spanContext = opts.spanContext;\r\n this._performanceStartTime = performance.now();\r\n this._performanceOffset =\r\n now - (this._performanceStartTime + performance.timeOrigin);\r\n this.startTime = this._getTime(opts.startTime ?? now);\r\n /* [...] */\r\n }\r\n\r\n private _getTime(inp?: TimeInput): HrTime {\r\n if (typeof inp === 'number') {\r\n if (inp <= this._performanceStartTime) {\r\n // performance.now() timestamp — apply offset to convert to wall-clock\r\n return hrTime(inp + this._performanceOffset);\r\n }\r\n // Date.now() timestamp\r\n return millisToHrTime(inp);\r\n }\r\n /* [...] */\r\n }\r\n```\r\n\r\nedit: running the benchmark multiple times results in a wide swing. Sometimes I get 900k ops/s and sometimes 600k. This does seem to improve the midpoint, but I am not 100% confident the benchmark is actually showing a r ...[truncated]", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "none", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", - "no_author_action", + "author_action", "author_action" ] }, @@ -7562,17 +7993,18 @@ "requester": "timfish", "pr_author": "biw", "review_state": null, + "root_timestamp": "2026-04-15T09:26:20Z", "body": "> In bundled ESM environments, that unnecessary hook can lead to runtime failures when the app later uses createRequire(), for example `ReferenceError: require is not defined`\r\n\r\nIt's not clear why ESM, bundling and `require-in-the-middle` causes the above to occur. Do you have a reproduction to try?\r\n\r\nIt feels like this PR works around an issue rather than actually finding and fixing the root cause!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7589,17 +8021,18 @@ "requester": "timfish", "pr_author": "biw", "review_state": null, + "root_timestamp": "2026-04-15T15:34:53Z", "body": "Ah, I see that essentially your PR [here](https://github.com/getsentry/sentry-electron/pull/1354) is a reproduction of the issue. I'll take a look!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -7616,17 +8049,18 @@ "requester": "timfish", "pr_author": "biw", "review_state": null, + "root_timestamp": "2026-04-15T15:49:07Z", "body": "@biw your example from the Electron PR referenced some really old dependencies. When I updated everything to below, it doesn't result in a runtime error.\r\n\r\n```json\r\n \"dependencies\": {\r\n \"electron-squirrel-startup\": \"^1.0.1\"\r\n },\r\n \"devDependencies\": {\r\n \"@sentry/electron\": \"7.11.0\",\r\n \"@sentry/vue\": \"10.47.0\",\r\n \"@vitejs/plugin-vue\": \"^6.0.6\",\r\n \"electron\": \"^41.2.0\",\r\n \"electron-vite\": \"^5.0.0\",\r\n \"vite\": \"^8.0.8\",\r\n \"vue\": \"^3.5.32\"\r\n }\r\n```\r\n\r\nIf you can supply a failing reproduction of the issue I might be able to help further.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7643,17 +8077,18 @@ "requester": "pichlermarc", "pr_author": "biw", "review_state": null, + "root_timestamp": "2026-05-11T10:37:41Z", "body": "Hi @biw - were you able to repro this on more recent versions? 🙂", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7670,24 +8105,25 @@ "requester": "timfish", "pr_author": "biw", "review_state": null, + "root_timestamp": "2026-05-11T11:43:56Z", "body": "I would say this should be closed.\r\n\r\nRather than init `require-in-the-middle` lazily, there should be a way to create Node instrumentations that don't use `require-in-the-middle` and `import-in-the-middle` at all. ie. some higher level base instrumentation that doesn't expect module hooking. This would be useful for instrumentations that use `TracingChannel`!", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -7697,44 +8133,18 @@ "requester": "maryliag", "pr_author": "cjihrig", "review_state": null, + "root_timestamp": "2026-04-16T14:50:03Z", "body": "from @pichlermarc on otel-js-dev channel:\r\n`We are planning to publish SDK 3.0 around June/July, and have a milestone set up for it already. I'd suggest we do it there and communicate the change accordingly.`\r\n\r\nI'm not sure when we can start adding changes only for 3.0. Can you provide guidance @pichlermarc ?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-issue-comment-5048923415", - "repo": "opentelemetry-js", - "pull_request": 6599, - "requester": "pichlermarc", - "pr_author": "cjihrig", - "review_state": null, - "body": "> > Waiting on: Author\r\n> \r\n> Is that accurate?\r\n\r\nno - automation made a mistake - we'll merge this once we start working on 3.0 :)", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ "no_author_action", @@ -7751,17 +8161,18 @@ "requester": "pichlermarc", "pr_author": "cjihrig", "review_state": "COMMENTED", + "root_timestamp": "2026-04-17T08:22:42Z", "body": "@maryliag - I thought it'd be best to do this at the same time as 3.x (possibly also bumping this package from experimental to stable in the process).\n\nI think this change will break a lot of users that rely on the default behavior being that it binds to all available network interfaces instead of `localhost`.\n\n**suggestion:** let's put a warning there for now, letting people know that this will only bind to `localhost` in the future. Once we're working on 3.x, we change the behavior and we release it together with 3.x, and include guidance on what to do in the migration document. This way people have some time to change their settings accordingly instead of being broken without warning.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7772,57 +8183,59 @@ ] }, { - "id": "pr-issue-comment-4341934910", + "id": "pr-issue-comment-5048923415", "repo": "opentelemetry-js", - "pull_request": 6634, - "requester": "david-luna", - "pr_author": "abhisheksurve45", + "pull_request": 6599, + "requester": "pichlermarc", + "pr_author": "cjihrig", "review_state": null, - "body": "@abhisheksurve45 thanks for your contribution. I left a comment about the scope of the new function. Maybe other @open-telemetry/javascript-approvers want to give their view.\r\n\r\nIn the meantime you may want to `npm run lint:fix` to make the CI happy", + "root_timestamp": "2026-07-22T16:46:14Z", + "body": "> > Waiting on: Author\r\n> \r\n> Is that accurate?\r\n\r\nno - automation made a mistake - we'll merge this once we start working on 3.0 :)", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", "author_action" ] }, { - "id": "pr-issue-comment-4451608995", + "id": "pr-issue-comment-4341934910", "repo": "opentelemetry-js", - "pull_request": 6653, - "requester": "ArthurSens", - "pr_author": "cjihrig", + "pull_request": 6634, + "requester": "david-luna", + "pr_author": "abhisheksurve45", "review_state": null, - "body": "Yep, 1200 LOC is a lot 😅. Let me try to parse that into human-readable text:\r\n\r\nUnderscore Scaping:\r\n* `metric@with#special$chars` -> `metric_with_special_chars`\r\n* `123metric` -> `_123metric` (metric names starting with digit are unnallowed unless UTF-8 is enabled)\r\n* `` (empty) -> Should error\r\n* `metric@@##$$name` -> `metric_name` (multiple special characters become a single underscore)\r\n* `@#$%` -> Should error since it's only special characters, translating into a single underscore\r\n\r\n\r\nNo underscore scaping:\r\n* The cases above are allowed untransformed, besides the empty string", + "root_timestamp": "2026-04-29T08:10:45Z", + "body": "@abhisheksurve45 thanks for your contribution. I left a comment about the scope of the new function. Maybe other @open-telemetry/javascript-approvers want to give their view.\r\n\r\nIn the meantime you may want to `npm run lint:fix` to make the CI happy", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ "no_author_action", + "author_action", "no_author_action", "no_author_action", - "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -7832,17 +8245,18 @@ "requester": "ArthurSens", "pr_author": "cjihrig", "review_state": "COMMENTED", + "root_timestamp": "2026-05-14T12:25:44Z", "body": "Hello, hello, thanks for starting the effort!\n\nI don't know JS at all, so I can't do a very complete review. \n\nLooking at your tests, and comparing them with the ones we did for go (https://github.com/prometheus/otlptranslator/blob/main/metric_namer_test.go), it seems like a lot of edge cases aren't covered here. Is it worth covering them?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7852,6 +8266,34 @@ "author_action" ] }, + { + "id": "pr-issue-comment-4451608995", + "repo": "opentelemetry-js", + "pull_request": 6653, + "requester": "ArthurSens", + "pr_author": "cjihrig", + "review_state": null, + "root_timestamp": "2026-05-14T14:30:04Z", + "body": "Yep, 1200 LOC is a lot 😅. Let me try to parse that into human-readable text:\r\n\r\nUnderscore Scaping:\r\n* `metric@with#special$chars` -> `metric_with_special_chars`\r\n* `123metric` -> `_123metric` (metric names starting with digit are unnallowed unless UTF-8 is enabled)\r\n* `` (empty) -> Should error\r\n* `metric@@##$$name` -> `metric_name` (multiple special characters become a single underscore)\r\n* `@#$%` -> Should error since it's only special characters, translating into a single underscore\r\n\r\n\r\nNo underscore scaping:\r\n* The cases above are allowed untransformed, besides the empty string", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, { "id": "pr-issue-comment-4475945089", "repo": "opentelemetry-js", @@ -7859,17 +8301,18 @@ "requester": "pichlermarc", "pr_author": "JPeer264", "review_state": null, + "root_timestamp": "2026-05-18T08:47:33Z", "body": "nice, almost there :) \r\nlooks like we still need a config\r\n\r\n\r\n**logs:**\r\n```\r\n/opt/hostedtoolcache/node/22.22.2/x64/bin/npx size-limit --json\r\nInstall Size Limit preset depends on type of the project\r\n\r\nFor application, where you send JS bundle directly to users\r\n npm install --save-dev @size-limit/preset-app\r\n\r\nFor frameworks, components and big libraries\r\n npm install --save-dev @size-limit/preset-big-lib\r\n\r\nFor small (< 10 kB) libraries\r\n npm install --save-dev @size-limit/preset-small-lib\r\n\r\nCheck out docs for more complicated cases\r\n https://github.com/ai/size-limit/\r\n```", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7886,17 +8329,18 @@ "requester": "pichlermarc", "pr_author": "JPeer264", "review_state": null, + "root_timestamp": "2026-05-18T08:49:36Z", "body": "or is the failure reason the one you mentioned in the PR description? 🤔", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7907,23 +8351,24 @@ ] }, { - "id": "pr-issue-comment-4694473862", + "id": "pr-review-4411677922", "repo": "opentelemetry-js", "pull_request": 6751, "requester": "overbalance", "pr_author": "devareddy05", - "review_state": null, - "body": "One more thing the 🤖 mentioned:\r\n\r\nShould a send timeout be classified as `retryable` instead of `failure`, given that the Node HTTP transport treats its own timeout as `retryable` (http-transport-utils.ts), or is the intent to keep the fetch transport's **existing** drop-on-timeout semantics?", + "review_state": "COMMENTED", + "root_timestamp": "2026-06-02T16:45:04Z", + "body": "Great fix! Just one question.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -7934,51 +8379,59 @@ ] }, { - "id": "pr-review-4411677922", + "id": "pr-review-4488338843", "repo": "opentelemetry-js", "pull_request": 6751, "requester": "overbalance", "pr_author": "devareddy05", "review_state": "COMMENTED", - "body": "Great fix! Just one question.", - "role": "context", - "stability": null, - "recorded_label": null, + "root_timestamp": "2026-06-12T19:02:51Z", + "body": "I think that covers the issues found for browsers. I'll be curious to see what's in the node review", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - null, - null, - null, - null, - null + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], - "run_labels": [] + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] }, { - "id": "pr-review-4488338843", + "id": "pr-issue-comment-4694473862", "repo": "opentelemetry-js", "pull_request": 6751, "requester": "overbalance", "pr_author": "devareddy05", - "review_state": "COMMENTED", - "body": "I think that covers the issues found for browsers. I'll be curious to see what's in the node review", + "review_state": null, + "root_timestamp": "2026-06-12T19:15:30Z", + "body": "One more thing the 🤖 mentioned:\r\n\r\nShould a send timeout be classified as `retryable` instead of `failure`, given that the Node HTTP transport treats its own timeout as `retryable` (http-transport-utils.ts), or is the intent to keep the fetch transport's **existing** drop-on-timeout semantics?", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -7988,17 +8441,18 @@ "requester": "pichlermarc", "pr_author": "ArthurSens", "review_state": "COMMENTED", + "root_timestamp": "2026-07-20T12:03:28Z", "body": "Sorry for the late review on this PR. I think having `AggreagationSelector` be a function was a mistake we made, since it implies that changing the returned values after configuring the `MetricReader` (in this case `PrometheusExporter`) would re-configure already-created instruments, which is not the case.\n\n**Suggestion:** let's implement this feature in a why that there's an `aggregationPreference` option that people can configure like so:\n\n```ts\nnew PrometheusExporter({\n aggregationPreference: {\n gauge: {\n // this here is an AggregationOption\n type: AggregationType.LAST_VALUE\n },\n // non-specified ones fall back to default\n }\n})\n```\n\nInternally, the `aggregationPreference` is converted to an `aggregationSelector` and published this way. This way it's clearer that nothing can be changed once the exporter has been instantiated. :)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8015,17 +8469,18 @@ "requester": "maryliag", "pr_author": "MikeGoldsmith", "review_state": "COMMENTED", + "root_timestamp": "2026-06-19T20:34:11Z", "body": "Great example! Thank you for adding!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8042,24 +8497,25 @@ "requester": "trentm", "pr_author": "MikeGoldsmith", "review_state": "COMMENTED", + "root_timestamp": "2026-07-09T21:54:20Z", "body": "A number of nits, but looks good to me (along with a proposal to have a separate \"telemetry.ts\").", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -8069,17 +8525,18 @@ "requester": "trentm", "pr_author": "pichlermarc", "review_state": "APPROVED", + "root_timestamp": "2026-07-20T21:02:54Z", "body": "LGTM. Thanks, Marc!\n\nI gather your `subscriberWithContextManagement` utility from https://github.com/open-telemetry/opentelemetry-js/pull/6387/changes#diff-516a26260144caf8cae79053916963fc7c5ca8aa24771ccc4d022b532c013b4c will need to be updated to use `token.dispose()`.\nHave you played with that?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8096,17 +8553,18 @@ "requester": "JacksonWeber", "pr_author": "buzztaiki", "review_state": null, + "root_timestamp": "2026-07-07T20:11:38Z", "body": "Please don't forget to include a changelog.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8123,17 +8581,18 @@ "requester": "pichlermarc", "pr_author": "matthieusieben", "review_state": null, + "root_timestamp": "2026-07-09T13:55:55Z", "body": "Hi @matthieusieben - thanks for opening this PR for discussion. This is actually an issue that's mentioned in our docs: https://opentelemetry.io/docs/concepts/context-propagation/#security-best-practices\r\n\r\n**Q:** why not strip these headers at at something like a reverse proxy so that these never end up in the app at all? I suppose the idea is to don't allow external callers to add trace context/baggage but to allow internal ones. This is the most common way I've seen this issue handled in production deployments.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8144,57 +8603,59 @@ ] }, { - "id": "pr-issue-comment-5001607465", + "id": "pr-review-4667212854", "repo": "opentelemetry-js", "pull_request": 6907, - "requester": "pichlermarc", + "requester": "trentm", "pr_author": "LarryHu0217", - "review_state": null, - "body": "> Also, it would be good to have a follow-up issue/PR that updates usage in this repo\r\n\r\nref: #6925", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-09T22:39:20Z", + "body": "Thanks for the PR. One requested change below.\n\n(Also, it would be good to have a follow-up issue/PR that updates usage in this repo. E.g. here: https://github.com/open-telemetry/opentelemetry-js/blob/a79c4a4fc27b1a29286e60de4e9ce884e7c23c58/experimental/packages/opentelemetry-sdk-node/src/utils.ts#L1353-L1386)", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "no_author_action", + "author_action", "no_author_action", "no_author_action", "no_author_action" ] }, { - "id": "pr-review-4667212854", + "id": "pr-issue-comment-5001607465", "repo": "opentelemetry-js", "pull_request": 6907, - "requester": "trentm", + "requester": "pichlermarc", "pr_author": "LarryHu0217", - "review_state": "COMMENTED", - "body": "Thanks for the PR. One requested change below.\n\n(Also, it would be good to have a follow-up issue/PR that updates usage in this repo. E.g. here: https://github.com/open-telemetry/opentelemetry-js/blob/a79c4a4fc27b1a29286e60de4e9ce884e7c23c58/experimental/packages/opentelemetry-sdk-node/src/utils.ts#L1353-L1386)", + "review_state": null, + "root_timestamp": "2026-07-17T09:40:00Z", + "body": "> Also, it would be good to have a follow-up issue/PR that updates usage in this repo\r\n\r\nref: #6925", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -8204,17 +8665,18 @@ "requester": "pichlermarc", "pr_author": "nissy-dev", "review_state": null, + "root_timestamp": "2026-07-17T16:20:16Z", "body": "Having `AggreagationSelector` be a function was a mistake we made, since it implies that changing the returned values after configuring the `MetricReader` (in this case `PrometheusExporter`) would re-configure already-created instruments, which is not the case.\r\n\r\n**Suggestion:** let's implement this feature in a why that there's an `aggregationPreference` option that people can configure like so.\r\n\r\n```ts\r\nnew PrometheusExporter({\r\n aggregationPreference: {\r\n gauge: {\r\n // this here is an AggregationOption\r\n type: AggregationType.LAST_VALUE\r\n },\r\n // non-specified ones fall back to default\r\n }\r\n})\r\n```\r\n\r\nInternally, the `aggregationPreference` is converted to an `aggregationSelector` and published this way.\r\nThis way it's clearer that nothing can be changed once the exporter has been instantiated. :)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8231,17 +8693,18 @@ "requester": "overbalance", "pr_author": "Babul422", "review_state": null, + "root_timestamp": "2026-07-27T15:06:28Z", "body": "@Babul422 This looks like a breaking change for gRPC. Have you tested it?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8258,17 +8721,18 @@ "requester": "overbalance", "pr_author": "Babul422", "review_state": null, + "root_timestamp": "2026-07-27T17:16:38Z", "body": "Right, but now they have differing behavior if your proposal is the new standard. I'll wait for others to chime in.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8285,103 +8749,109 @@ "requester": "pichlermarc", "pr_author": "lucas-gregoire", "review_state": null, + "root_timestamp": "2025-08-13T17:01:13Z", "body": "@lucas-gregoire - looks like the messaging semantic conventions are not *actually* stable yet, so this PR is blocked until is is formally marked as such. \r\n\r\n(Unless this is part of an effort to create prototypes to mark the messaging semconv as stable, if that is the case, please link the corresponding issue from SemConv here, thanks 🙂)", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { - "id": "pr-issue-comment-3329833194", + "id": "pr-review-3206929990", "repo": "opentelemetry-js-contrib", "pull_request": 2976, "requester": "trentm", "pr_author": "lucas-gregoire", - "review_state": null, - "body": "Some context: We discussed this in the OTel JS SIG call today. Doing semconv changes to this instrumentation to get it closer to the current semconv spec state isn't *blocked* until messaging semconv is stabilized. However, because messaging semconv isn't stable yet, we cannot *call these changes \"stable\"* and we probably shouldn't use the `OTEL_SEMCONV_STABILITY_OPT_IN` envvar.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2025-09-10T16:31:13Z", + "body": "See comments above.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ - "no_author_action", "author_action", "author_action", "author_action", + "no_author_action", "author_action" ] }, { - "id": "pr-issue-comment-3415202969", + "id": "pr-issue-comment-3329833194", "repo": "opentelemetry-js-contrib", "pull_request": 2976, - "requester": "pichlermarc", + "requester": "trentm", "pr_author": "lucas-gregoire", "review_state": null, - "body": "I opened https://github.com/open-telemetry/semantic-conventions/issues/2928 on the semconv repo to find a way how we could accept this change. With that proposal we would be able to use `messaging_latest_experimental` over `messaging` for updating to newer experimental semconv.", + "root_timestamp": "2025-09-24T16:47:07Z", + "body": "Some context: We discussed this in the OTel JS SIG call today. Doing semconv changes to this instrumentation to get it closer to the current semconv spec state isn't *blocked* until messaging semconv is stabilized. However, because messaging semconv isn't stable yet, we cannot *call these changes \"stable\"* and we probably shouldn't use the `OTEL_SEMCONV_STABILITY_OPT_IN` envvar.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", "author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-3206929990", + "id": "pr-issue-comment-3415202969", "repo": "opentelemetry-js-contrib", "pull_request": 2976, - "requester": "trentm", + "requester": "pichlermarc", "pr_author": "lucas-gregoire", - "review_state": "CHANGES_REQUESTED", - "body": "See comments above.", - "role": "context", - "stability": null, + "review_state": null, + "root_timestamp": "2025-10-17T11:49:44Z", + "body": "I opened https://github.com/open-telemetry/semantic-conventions/issues/2928 on the semconv repo to find a way how we could accept this change. With that proposal we would be able to use `messaging_latest_experimental` over `messaging` for updating to newer experimental semconv.", + "role": "scored", + "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - null, - null, - "none", - "none", - "none" + "author_action", + "no_author_action", + "no_author_action", + "author_action", + "author_action" ], "run_labels": [ + "author_action", "no_author_action", "no_author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -8391,17 +8861,18 @@ "requester": "pichlermarc", "pr_author": "PavelPashov", "review_state": null, + "root_timestamp": "2025-11-05T17:53:13Z", "body": "cc @blumamir @naseemkullah (component owners)", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8418,17 +8889,18 @@ "requester": "overbalance", "pr_author": "renovate", "review_state": null, + "root_timestamp": "2025-12-10T20:28:24Z", "body": "Fixes and makes #3276 redundant", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8439,84 +8911,87 @@ ] }, { - "id": "pr-issue-comment-3557921479", + "id": "pr-review-3487419552", "repo": "opentelemetry-js-contrib", "pull_request": 3231, "requester": "pichlermarc", "pr_author": "thompson-tomo", - "review_state": null, - "body": ">Would it work if we add an explicit don't pin dev otel package rule?\r\n\r\nCould work. But also I think we're kind of okay with the settings we have now. Though, we may want to have our actions pinned, and potentially images pinned too as we did in the core repo.\r\n\r\nOther than that I don't think we necessarily need this change and I suspect blindly applying best practice settings right now will make us spend a lot of time sorting though issues that don't really move the needle for anyone. I'd leave it to folks that regularly update dependencies in this repo and have a feeling about what usually goes wrong with these sorts of things.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2025-11-20T11:52:47Z", + "body": "This repo is very delicate with its dependencies. \n\nEssentially I agree most of what this PR is doing **except for the catch-all `:pinDevDependencies`** - we have a lockfile so that the few `devDependencies` that are unpinned don't cause havoc.", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-issue-comment-3562195334", + "id": "pr-issue-comment-3557921479", "repo": "opentelemetry-js-contrib", "pull_request": 3231, "requester": "pichlermarc", "pr_author": "thompson-tomo", "review_state": null, - "body": "> So what prompted me to look at this was the fact that markdownlint was not reporting violations. What I saw was markdownlint was out of date and was pinned on the old one. I know from other projects pinning dev dependencies resulted in them being updated. \r\n\r\nThe problem here is not pinning. We have dependency Dependency Dashboard approvals on for most packages.\r\n\r\nWe don't update all packages at once since we have a massive amount of them here in this repo. We found that:\r\n- auto updating packages individually takes time away from reviewing contributions made by real people.\r\n- auto updating package in batches makes it pretty much impossible to troubleshoot when something goes wrong, you'll have to update on a package-by-package basis anyway.\r\n\r\nBoth approaches burnt people out as they had to deal with dependency updates all day. Some worked immediately, some did not. But all of them took visibility away from actual PRs people opened. So I pulled the plug on it and made Dashboard Approvals required. That means that if somebody has a few minutes to spare and they have Triage permissions on the repo, they can trigger and update and work through any problems without it always being ...[truncated]", + "root_timestamp": "2025-11-20T12:56:47Z", + "body": ">Would it work if we add an explicit don't pin dev otel package rule?\r\n\r\nCould work. But also I think we're kind of okay with the settings we have now. Though, we may want to have our actions pinned, and potentially images pinned too as we did in the core repo.\r\n\r\nOther than that I don't think we necessarily need this change and I suspect blindly applying best practice settings right now will make us spend a lot of time sorting though issues that don't really move the needle for anyone. I'd leave it to folks that regularly update dependencies in this repo and have a feeling about what usually goes wrong with these sorts of things.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ + "author_action", + "author_action", "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", + "author_action", "no_author_action" ] }, { - "id": "pr-review-3487419552", + "id": "pr-issue-comment-3562195334", "repo": "opentelemetry-js-contrib", "pull_request": 3231, "requester": "pichlermarc", "pr_author": "thompson-tomo", - "review_state": "CHANGES_REQUESTED", - "body": "This repo is very delicate with its dependencies. \n\nEssentially I agree most of what this PR is doing **except for the catch-all `:pinDevDependencies`** - we have a lockfile so that the few `devDependencies` that are unpinned don't cause havoc.", + "review_state": null, + "root_timestamp": "2025-11-21T09:39:54Z", + "body": "> So what prompted me to look at this was the fact that markdownlint was not reporting violations. What I saw was markdownlint was out of date and was pinned on the old one. I know from other projects pinning dev dependencies resulted in them being updated. \r\n\r\nThe problem here is not pinning. We have dependency Dependency Dashboard approvals on for most packages.\r\n\r\nWe don't update all packages at once since we have a massive amount of them here in this repo. We found that:\r\n- auto updating packages individually takes time away from reviewing contributions made by real people.\r\n- auto updating package in batches makes it pretty much impossible to troubleshoot when something goes wrong, you'll have to update on a package-by-package basis anyway.\r\n\r\nBoth approaches burnt people out as they had to deal with dependency updates all day. Some worked immediately, some did not. But all of them took visibility away from actual PRs people opened. So I pulled the plug on it and made Dashboard Approvals required. That means that if somebody has a few minutes to spare and they have Triage permissions on the repo, they can trigger and update and work through any problems without it always being ...[truncated]", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "author_action", "author_action", + "no_author_action", "author_action", - "author_action", - "author_action" + "no_author_action" ] }, { @@ -8526,24 +9001,53 @@ "requester": "overbalance", "pr_author": "renovate", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-01-16T15:14:35Z", "body": "See linked PR that was manually updated.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ "no_author_action", "no_author_action", + "author_action", "no_author_action", - "no_author_action", - "no_author_action" + "author_action" + ] + }, + { + "id": "pr-review-3627365065", + "repo": "opentelemetry-js-contrib", + "pull_request": 3328, + "requester": "maryliag", + "pr_author": "lukeramsden", + "review_state": "COMMENTED", + "root_timestamp": "2026-01-05T15:42:49Z", + "body": "Thank you for your contribution.\r\nYou will need to add a changelog and tests to this PR before we can merge it.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -8553,17 +9057,18 @@ "requester": "trentm", "pr_author": "lukeramsden", "review_state": null, + "root_timestamp": "2026-01-13T19:35:56Z", "body": "> You will need to add a changelog and tests to this PR before we can merge it.\r\n\r\n@maryliag This gets me and I have to check again almost everytime. The **core** repo requires PRs to explicitly include a CHANGELOG.md entry. The **contrib** repo does not, because the release process automatically adds changelog entries based on the commit titles.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8580,17 +9085,18 @@ "requester": "maryliag", "pr_author": "lukeramsden", "review_state": null, + "root_timestamp": "2026-01-13T21:28:16Z", "body": ">The contrib repo does not\r\n\r\nthis is what I get for having a bunch of tabs open to review and not checking the repo 🤦 \r\nNow just wait for tests to pass then 😄", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8607,17 +9113,18 @@ "requester": "pichlermarc", "pr_author": "lukeramsden", "review_state": null, + "root_timestamp": "2026-01-16T14:03:47Z", "body": "Silly question: is this not what the `View` concept is for (defining a custom aggregation based on meter+metric name?)\r\nhttps://opentelemetry.io/docs/languages/js/instrumentation/#configure-metric-views", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8634,17 +9141,18 @@ "requester": "pichlermarc", "pr_author": "lukeramsden", "review_state": null, + "root_timestamp": "2026-01-16T15:07:42Z", "body": "> > Silly question: is this not what the `View` concept is for (defining a custom aggregation based on meter+metric name?) https://opentelemetry.io/docs/languages/js/instrumentation/#configure-metric-views\r\n> \r\n> Does that work if the view buckets are more granular or have larger ranges than the underlying histogram? I've never heard of views and no idea how they work internally (and docs aren't clear)\r\n\r\nYes. The underlying mechanism the same for `View` and `advice` - when you use `Histogram#record()` it passes the data to the `Aggregation` that was created based on either the default, the `advice` or the `View`. In any case, you'll not loose data-granularity and there's no estimation going on.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8661,51 +9169,25 @@ "requester": "david-luna", "pr_author": "lukeramsden", "review_state": null, + "root_timestamp": "2026-02-02T15:03:51Z", "body": "@lukeramsden did you have time to review the latest comments?", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", - "no_author_action", "author_action", "author_action", - "author_action" - ] - }, - { - "id": "pr-review-3627365065", - "repo": "opentelemetry-js-contrib", - "pull_request": 3328, - "requester": "maryliag", - "pr_author": "lukeramsden", - "review_state": "COMMENTED", - "body": "Thank you for your contribution.\r\nYou will need to add a changelog and tests to this PR before we can merge it.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "no_author_action" ], "run_labels": [ "author_action", "author_action", "author_action", "author_action", - "author_action" + "no_author_action" ] }, { @@ -8715,17 +9197,18 @@ "requester": "dyladan", "pr_author": "RaphaelManke", "review_state": null, + "root_timestamp": "2026-04-15T16:59:16Z", "body": "Is there any sort of spec or documentation for this feature? Can we be certain this will always continue to work into the future?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8742,17 +9225,18 @@ "requester": "raphael-theriault-swi", "pr_author": "RaphaelManke", "review_state": "COMMENTED", + "root_timestamp": "2026-03-09T17:12:30Z", "body": "Solution looks good, but I'm wondering whether we might want to tackle this from the instrumentation package given it's not technically unique to Lambda", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8769,17 +9253,18 @@ "requester": "david-luna", "pr_author": "neilime", "review_state": null, + "root_timestamp": "2026-04-14T13:06:30Z", "body": "Hi @neilime \r\n\r\nThanks for working on this. I'm okay with having a new and more generic instrumentation (let's wait for more feedback). IMHO I would split this PR into smaller ones with this order\r\n\r\n- [ ] PR to add the new instrumentation (this one)\r\n- [ ] wait for the publication of the new instrumentation\r\n- [ ] PR to add the deprecation notice into `@opentelemetry/instrumentation-nestjs-core`\r\n- [ ] PR to replace it in auto instrumentations\r\n- [ ] after a period of time remove the deprecated instrumentation. Leaving a README for people looking at the instrumentation\r\n\r\n`@opentelemetry/instrumentation-fastify` had a similar process. Ref: https://github.com/open-telemetry/opentelemetry-js-contrib/issues/2647\r\n\r\nIf you agree with this process I think this PR should only contain the new instrumentation. And I'd prefer to not refactor the current instrumentation so we avoid maintenance on it.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8796,17 +9281,18 @@ "requester": "david-luna", "pr_author": "neilime", "review_state": null, + "root_timestamp": "2026-04-29T08:59:09Z", "body": "@neilime any feedback from my previous comment?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8823,17 +9309,18 @@ "requester": "jj22ee", "pr_author": "garysassano", "review_state": "COMMENTED", + "root_timestamp": "2026-06-23T00:55:09Z", "body": "Hey @garysassano, I was interested in the cold-start impact since this detector previously only read environment variables and this adds an HTTP request on the init path.\n\nI compared the current detector vs. this PR, on average (10 runs) the one-time cold-start cost was `+53 ms` at `128 MB` and `+5.5 ms` at `512 MB` of memory. So the performance impact seems okay, wondering if you had similar results or other thoughts?\n\nRegarding populating `cloud.availability_zone` with the AZ ID instead of the AZ name, it technically still fits the spec, but it will be inconsistent with the other AWS EC2 and ECS detectors in this package, which set the value to be the AZ name instead. So I suppose if consumers tries to ever query resources grouped by `cloud.availability_zone`, they'd need to account for this discrepancy. Given the limitation of Lambda only exposing the ID, I think this is okay for now, as you also mentioned in the description. I'm thinking that if the AZ name is ever exposed in the future (if that even makes sense for Lambda), we should switch to it as a breaking change. For now, could you leave a comment under `_fetchAvailabilityZone along` these lines?\n```\n// Lambda's metadata ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8850,17 +9337,18 @@ "requester": "david-luna", "pr_author": "Genmin", "review_state": null, + "root_timestamp": "2026-05-13T13:56:35Z", "body": "@Genmin thanks for your contribution. Could you please sign the CLA so we can move on with this PR?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8877,26 +9365,27 @@ "requester": "david-luna", "pr_author": "Genmin", "review_state": null, + "root_timestamp": "2026-06-22T12:53:17Z", "body": "@Genmin \r\n\r\nCLA is still missing. Did you have any issue signing it?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-4381375506", "repo": "opentelemetry-js-contrib", @@ -8904,23 +9393,24 @@ "requester": "raphael-theriault-swi", "pr_author": "ElfoLiNk", "review_state": null, + "root_timestamp": "2026-05-05T17:04:00Z", "body": "ref #3379", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "author_action", "no_author_action", "no_author_action", + "author_action", + "no_author_action" + ], + "run_labels": [ + "author_action", "no_author_action", "no_author_action", + "author_action", "no_author_action" ] }, @@ -8931,17 +9421,18 @@ "requester": "trentm", "pr_author": "renovate", "review_state": null, + "root_timestamp": "2026-07-08T19:00:30Z", "body": "I briefly tried to get instr-koa working with `@koa/router@15` changes, but fell short and moved on.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -8952,23 +9443,24 @@ ] }, { - "id": "pr-issue-comment-4984441074", + "id": "pr-review-4686551165", "repo": "opentelemetry-js-contrib", "pull_request": 3620, "requester": "maryliag", "pr_author": "tejaswiverma121-byte", - "review_state": null, - "body": "@tejaswiverma121-byte we won't be able to merge this PR, because it doesn't follow the spec. \r\nA few other languages have the value of the collection easily available, but JS + PG doesn't, which is why you had to parse the query text, which is something that the spec tells you're not suppose to do.\r\nFor this reason, this feature can't be implemented here.\r\n\r\nI'm going to ask you to update the README instead, clarifying that this attribute is not being collected and that is expected. You can make the update in this PR (after reverting all the other changes) or if it's easier, just close this PR and open a new one with just the readme update.\r\n\r\nI appreciate you working on this either way!", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-13T16:22:25Z", + "body": "thank you for working on this! You do have a lot of failed tests, so make sure those are fixed. I also added a few more test cases that should be added", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -8979,57 +9471,59 @@ ] }, { - "id": "pr-review-4686551165", + "id": "pr-review-4694490152", "repo": "opentelemetry-js-contrib", "pull_request": 3620, "requester": "maryliag", "pr_author": "tejaswiverma121-byte", "review_state": "COMMENTED", - "body": "thank you for working on this! You do have a lot of failed tests, so make sure those are fixed. I also added a few more test cases that should be added", + "root_timestamp": "2026-07-14T13:11:10Z", + "body": "I added a few suggestion to help performance, but I'm still debating if this is the right approach for this feature.\n\nIn the spec we have: \"The collection name SHOULD NOT be extracted from db.query.text, when the database system supports query text with multiple collections in non-batch operations.\", which is the case for PG.\n\nPart of it is because the query can have several tables, so it can be hard to decide which one to select, but also because parsing itself can be very costly. If we have a lot of queries being executed, having to match the regex can be an issue for the performance, so I'm thinking there could be an opt-in somehow, at least initially.\nI'll discuss this with the maintainers on our weekly (wednesday), and get back to you.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-review-4694490152", + "id": "pr-issue-comment-4984441074", "repo": "opentelemetry-js-contrib", "pull_request": 3620, "requester": "maryliag", "pr_author": "tejaswiverma121-byte", - "review_state": "COMMENTED", - "body": "I added a few suggestion to help performance, but I'm still debating if this is the right approach for this feature.\n\nIn the spec we have: \"The collection name SHOULD NOT be extracted from db.query.text, when the database system supports query text with multiple collections in non-batch operations.\", which is the case for PG.\n\nPart of it is because the query can have several tables, so it can be hard to decide which one to select, but also because parsing itself can be very costly. If we have a lot of queries being executed, having to match the regex can be an issue for the performance, so I'm thinking there could be an opt-in somehow, at least initially.\nI'll discuss this with the maintainers on our weekly (wednesday), and get back to you.", + "review_state": null, + "root_timestamp": "2026-07-15T19:21:05Z", + "body": "@tejaswiverma121-byte we won't be able to merge this PR, because it doesn't follow the spec. \r\nA few other languages have the value of the collection easily available, but JS + PG doesn't, which is why you had to parse the query text, which is something that the spec tells you're not suppose to do.\r\nFor this reason, this feature can't be implemented here.\r\n\r\nI'm going to ask you to update the README instead, clarifying that this attribute is not being collected and that is expected. You can make the update in this PR (after reverting all the other changes) or if it's easier, just close this PR and open a new one with just the readme update.\r\n\r\nI appreciate you working on this either way!", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -9039,17 +9533,18 @@ "requester": "hectorhdzg", "pr_author": "bhuvan-somisetty", "review_state": null, + "root_timestamp": "2026-07-22T16:56:30Z", "body": "Same pattern is used in https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/scripts/bitrot.mjs it would be good to cover that one as well", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9066,17 +9561,18 @@ "requester": "hectorhdzg", "pr_author": "bhuvan-somisetty", "review_state": "APPROVED", + "root_timestamp": "2026-07-22T18:05:28Z", "body": "LGTM, I validated on my side, fix is working in Windows machines", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9093,17 +9589,18 @@ "requester": "maryliag", "pr_author": "sethrylan", "review_state": "COMMENTED", + "root_timestamp": "2026-07-23T15:44:10Z", "body": "Thank you for working on this!\nCan you also update the readme for this package, to include the new metric", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9120,17 +9617,46 @@ "requester": "overbalance", "pr_author": "rycont", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T17:17:32Z", "body": "Nice catch! Thanks", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, + { + "id": "pr-review-785978965", + "repo": "opentelemetry-proto", + "pull_request": 340, + "requester": "tigrannajaryan", + "pr_author": "hdost", + "review_state": "APPROVED", + "root_timestamp": "2021-10-21T17:06:21Z", + "body": "I don't have a way to verify the change. If anyone is able please do.", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9147,17 +9673,18 @@ "requester": "tigrannajaryan", "pr_author": "hdost", "review_state": null, + "root_timestamp": "2022-07-06T14:44:04Z", "body": "@open-telemetry/specs-approvers can anyone review/verify this PR? If no-one knows how I am going to close it as \"stale\".", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9174,17 +9701,18 @@ "requester": "marcalff", "pr_author": "hdost", "review_state": null, + "root_timestamp": "2023-12-14T21:41:14Z", "body": "Related:\r\n\r\n* https://github.com/open-telemetry/opentelemetry-cpp/pull/2455", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9201,17 +9729,18 @@ "requester": "marcalff", "pr_author": "hdost", "review_state": null, + "root_timestamp": "2023-12-18T09:13:59Z", "body": "@hdost \r\n\r\nPlease note that I used `-z`, lowercase, not `-Z`, uppercase, for https://github.com/open-telemetry/opentelemetry-cpp/pull/2455. Not sure which one you need to generate proto files.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9228,17 +9757,18 @@ "requester": "tigrannajaryan", "pr_author": "hdost", "review_state": null, + "root_timestamp": "2023-12-18T15:24:28Z", "body": "@marcalff @ThomsonTan can you please review this PR? If we get both your approvals we should be able to move forward.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9249,23 +9779,24 @@ ] }, { - "id": "pr-issue-comment-2002637963", + "id": "pr-review-1788417893", "repo": "opentelemetry-proto", "pull_request": 340, - "requester": "tigrannajaryan", + "requester": "marcalff", "pr_author": "hdost", - "review_state": null, - "body": "@open-telemetry/specs-approvers please take a look. I think this is good to merge and verified to work by @marcalff.", + "review_state": "APPROVED", + "root_timestamp": "2023-12-19T09:10:32Z", + "body": "Verified that code generation fails without the fix for SELINUX systems.\r\n\r\n```\r\n[malff@malff-desktop opentelemetry-proto]$ make\r\nrm -rf ./gen/cpp\r\nmkdir -p ./gen/cpp\r\ndocker run --rm -u 1000 -v/data/malff/CODE/MY_GITHUB/opentelemetry-proto:/data/malff/CODE/MY_GITHUB/opentelemetry-proto -w/data/malff/CODE/MY_GITHUB/opentelemetry-proto otel/build-protobuf:0.9.0 --proto_path=/data/malff/CODE/MY_GITHUB/opentelemetry-proto --cpp_out=./gen/cpp opentelemetry/proto/resource/v1/resource.proto\r\nEmulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.\r\nopentelemetry/proto/resource/v1/resource.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file. Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).\r\nmake: *** [Makefile:56: gen-cpp] Error 1\r\n```\r\n\r\nVerified that code generation works with the fix for SELINUX systems.\r\n\r\nApproved, thanks for the fix.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9276,23 +9807,24 @@ ] }, { - "id": "pr-issue-comment-4064149827", + "id": "pr-issue-comment-2002637963", "repo": "opentelemetry-proto", "pull_request": 340, - "requester": "bogdandrutu", + "requester": "tigrannajaryan", "pr_author": "hdost", "review_state": null, - "body": "@tigrannajaryan should we put the effort to merge this ?", + "root_timestamp": "2024-03-17T22:25:00Z", + "body": "@open-telemetry/specs-approvers please take a look. I think this is good to merge and verified to work by @marcalff.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9303,23 +9835,24 @@ ] }, { - "id": "pr-review-1788417893", + "id": "pr-issue-comment-4064149827", "repo": "opentelemetry-proto", "pull_request": 340, - "requester": "marcalff", + "requester": "bogdandrutu", "pr_author": "hdost", - "review_state": "APPROVED", - "body": "Verified that code generation fails without the fix for SELINUX systems.\r\n\r\n```\r\n[malff@malff-desktop opentelemetry-proto]$ make\r\nrm -rf ./gen/cpp\r\nmkdir -p ./gen/cpp\r\ndocker run --rm -u 1000 -v/data/malff/CODE/MY_GITHUB/opentelemetry-proto:/data/malff/CODE/MY_GITHUB/opentelemetry-proto -w/data/malff/CODE/MY_GITHUB/opentelemetry-proto otel/build-protobuf:0.9.0 --proto_path=/data/malff/CODE/MY_GITHUB/opentelemetry-proto --cpp_out=./gen/cpp opentelemetry/proto/resource/v1/resource.proto\r\nEmulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.\r\nopentelemetry/proto/resource/v1/resource.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file. Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).\r\nmake: *** [Makefile:56: gen-cpp] Error 1\r\n```\r\n\r\nVerified that code generation works with the fix for SELINUX systems.\r\n\r\nApproved, thanks for the fix.", + "review_state": null, + "root_timestamp": "2026-03-15T23:20:36Z", + "body": "@tigrannajaryan should we put the effort to merge this ?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9330,23 +9863,24 @@ ] }, { - "id": "pr-review-785978965", + "id": "pr-review-2880303424", "repo": "opentelemetry-proto", - "pull_request": 340, - "requester": "tigrannajaryan", - "pr_author": "hdost", - "review_state": "APPROVED", - "body": "I don't have a way to verify the change. If anyone is able please do.", + "pull_request": 664, + "requester": "pellared", + "pr_author": "DylanRussell", + "review_state": "COMMENTED", + "root_timestamp": "2025-05-30T06:31:32Z", + "body": "In general, LGTM", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9363,17 +9897,18 @@ "requester": "pellared", "pr_author": "DylanRussell", "review_state": null, + "root_timestamp": "2025-07-01T15:33:31Z", "body": "@DylanRussell, given https://github.com/open-telemetry/opentelemetry-proto/pull/669 is merged I think you can update this PR :wink:", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9390,17 +9925,18 @@ "requester": "pellared", "pr_author": "DylanRussell", "review_state": null, + "root_timestamp": "2025-07-30T16:28:04Z", "body": "@open-telemetry/spec-sponsors, @open-telemetry/technical-committee, PTAL", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9411,86 +9947,61 @@ ] }, { - "id": "pr-issue-comment-3206632845", + "id": "pr-review-3136851451", "repo": "opentelemetry-proto", "pull_request": 664, "requester": "tigrannajaryan", "pr_author": "DylanRussell", - "review_state": null, - "body": "I think we need a description of how the new and old implementations should interoperate. Explain the operation in the following 3 scenarios:\r\n- Old client implementing the spec before this change connects to a new server implementing the spec after this change.\r\n- New client connects to old server.\r\n- New client connects to new server.", + "review_state": "COMMENTED", + "root_timestamp": "2025-08-20T14:17:43Z", + "body": "@DylanRussell can you please also attach a prototype implementation that shows how this works? You can take existing implementation in one of the languages or in the Collector and fork/modify it to demonstrate the change. Collectors otlp receiver/exporter fork would be ideal since it shows both the client and server side.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-2880303424", - "repo": "opentelemetry-proto", - "pull_request": 664, - "requester": "pellared", - "pr_author": "DylanRussell", - "review_state": "COMMENTED", - "body": "In general, LGTM", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-3136851451", + "id": "pr-issue-comment-3206632845", "repo": "opentelemetry-proto", "pull_request": 664, "requester": "tigrannajaryan", "pr_author": "DylanRussell", - "review_state": "COMMENTED", - "body": "@DylanRussell can you please also attach a prototype implementation that shows how this works? You can take existing implementation in one of the languages or in the Collector and fork/modify it to demonstrate the change. Collectors otlp receiver/exporter fork would be ideal since it shows both the client and server side.", + "review_state": null, + "root_timestamp": "2025-08-20T14:21:42Z", + "body": "I think we need a description of how the new and old implementations should interoperate. Explain the operation in the following 3 scenarios:\r\n- Old client implementing the spec before this change connects to a new server implementing the spec after this change.\r\n- New client connects to old server.\r\n- New client connects to new server.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-4209062361", "repo": "opentelemetry-proto", @@ -9498,17 +10009,18 @@ "requester": "aalexand", "pr_author": "jhalliday", "review_state": null, + "root_timestamp": "2026-04-08T19:33:27Z", "body": "A bit unusual to have such a large value in the dictionary but makes sense overall.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9518,6 +10030,34 @@ "no_author_action" ] }, + { + "id": "pr-review-4725154458", + "repo": "opentelemetry-proto", + "pull_request": 827, + "requester": "ps-mir", + "pr_author": "jsuereth", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-17T18:42:39Z", + "body": "Removing dependency from `rules_go` solves bazel 9.x issues. \r\n\r\nOn BCR release, unless bcr publish workflow allows generating MODULE.bazel similar to build-check.yaml, this might get stuck with same error.\r\n\r\n`Keeping bazel out of core` and `Automated BCR` seems mutually exclusive unless there is way include bazel files in release archive. Happy to be proven wrong, and learn something new.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-5006896916", "repo": "opentelemetry-proto", @@ -9525,17 +10065,18 @@ "requester": "ps-mir", "pr_author": "jsuereth", "review_state": null, + "root_timestamp": "2026-07-17T19:43:47Z", "body": "> What we do _not_ do in this proto repo is generate client libraries that are consumable by others, we expect that to be owned/maintained donwstream. E.g. In many Otel SDKs / Collector there's bespoke / optimised OTLP proto generation that wouldn't use the protoc generated code.\r\n\r\nThe approach makes more sense given this ask. I'm still doubtful about overlay as I haven't seen any working example or doc references. I'll keep digging.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9552,48 +10093,22 @@ "requester": "ps-mir", "pr_author": "jsuereth", "review_state": null, + "root_timestamp": "2026-07-19T09:53:45Z", "body": "Overlay won't be useful as its a downstream mechanism/control for non bazel upstream deps. It can be done locally, and also in BCR by creating manual entry with Overlay (BCR release process so far).\r\n\r\nBut automated BCR needs the lib to be bazel module, and a bazel module cannot be overlayed (Immutable entry in BCR).\r\n\r\nAssuming automated BCR is still preferred, the cleanest way is to make it a bazel module, and release proto only as baseline, let downstream generate the lib bindings.\r\n\r\nIf more time is needed for downstream community, we have to include proto+lang bindings (same as last BCR overlay) before eventually switching to proto only release.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4725154458", - "repo": "opentelemetry-proto", - "pull_request": 827, - "requester": "ps-mir", - "pr_author": "jsuereth", - "review_state": "COMMENTED", - "body": "Removing dependency from `rules_go` solves bazel 9.x issues. \r\n\r\nOn BCR release, unless bcr publish workflow allows generating MODULE.bazel similar to build-check.yaml, this might get stuck with same error.\r\n\r\n`Keeping bazel out of core` and `Automated BCR` seems mutually exclusive unless there is way include bazel files in release archive. Happy to be proven wrong, and learn something new.", - "role": "scored", - "stability": "flaky", - "recorded_label": null, - "adjudicated_label": null, - "run_actions": [ - "author", - "none", - "author", - "author", - "author" ], "run_labels": [ "author_action", - "no_author_action", + "author_action", "author_action", "author_action", "author_action" @@ -9606,17 +10121,18 @@ "requester": "lzchen", "pr_author": "Jwrede", "review_state": null, + "root_timestamp": "2026-07-07T16:30:16Z", "body": "@lmolkova \r\n\r\nDoes this pr have conflicts with https://github.com/open-telemetry/opentelemetry-python-genai/pull/90?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9633,17 +10149,18 @@ "requester": "lzchen", "pr_author": "Nik-Reddy", "review_state": null, + "root_timestamp": "2026-06-08T13:52:35Z", "body": "Hi @Nik-Reddy , will have to wait for a maintainer to merge.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ "no_author_action", @@ -9660,21 +10177,22 @@ "requester": "eternalcuriouslearner", "pr_author": "Nik-Reddy", "review_state": null, + "root_timestamp": "2026-06-21T19:19:23Z", "body": "@lmolkova I am thinking we can use openinference for adding instrumentation coverage for cohere. wdyt?", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "author_action", + "no_author_action", "no_author_action", "no_author_action", "no_author_action" @@ -9687,24 +10205,25 @@ "requester": "lmolkova", "pr_author": "Nik-Reddy", "review_state": null, + "root_timestamp": "2026-06-26T04:46:48Z", "body": "> @lmolkova I am thinking we can use openinference for adding instrumentation coverage for cohere. wdyt?\r\n\r\nit doesn't seem like they have instrumentation for it", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -9714,17 +10233,18 @@ "requester": "lmolkova", "pr_author": "Nik-Reddy", "review_state": "COMMENTED", + "root_timestamp": "2026-07-22T19:36:45Z", "body": "A few more comments. \n\nThe key question, @Nik-Reddy are you going to follow up with real instrumentation right away? We already have a couple of empty instrumentations in this repo and unless you'd like to work on actual cohere instrumentation, I would prefer to not add another one.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9741,17 +10261,18 @@ "requester": "eternalcuriouslearner", "pr_author": "wrisa", "review_state": null, + "root_timestamp": "2026-07-08T14:50:26Z", "body": "Everything LGTM!! We can wait till this https://github.com/open-telemetry/semantic-conventions-genai/issues/344 is addressed as I believe we need to update semantic conventions and bring in new semconv package. Lmk Wdyt @wrisa .", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9768,23 +10289,24 @@ "requester": "eternalcuriouslearner", "pr_author": "YuxiangJiangCT", "review_state": null, + "root_timestamp": "2026-06-19T21:10:46Z", "body": "Howdy there!! Thanks for your contribution. PR looks good to me. I had few questions around the direction we want to take for this issue, so I posted few questions on the issue. We will get to this once those are confirmed.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", + "author_action", "no_author_action" ] }, @@ -9795,44 +10317,46 @@ "requester": "lmolkova", "pr_author": "YuxiangJiangCT", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-21T00:15:13Z", "body": "This PR covers up a bigger issue that we, instead of returning original stream, we return parsed one that has different API shape.\n\nI'm proposing to fix the bigger issue here - https://github.com/open-telemetry/opentelemetry-python-genai/pull/278 so that we keep instrumentation transparent and don't modify types / expectations from pure underlying libraries.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "author", - "author", - "none" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", "no_author_action", "author_action", "author_action", - "no_author_action" + "author_action", + "author_action" ] }, { - "id": "pr-issue-comment-4976059665", + "id": "pr-review-4698657099", "repo": "opentelemetry-python-genai", "pull_request": 247, - "requester": "eternalcuriouslearner", + "requester": "lmolkova", "pr_author": "123liuziming", - "review_state": null, - "body": "@lmolkova do you think we should separate this into two PRs like say:\n\n1. Basic setup(examples, gh, lint and other setup) for agent scope like we did in python contrib.\n2. Add all the instrumentation as this is a donation.\n\nThis might basically reduce the cognitive load on reviewers. Wdyt?", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-14T23:12:15Z", + "body": "LGTM, just some minor questions and concerns around build and release", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -9843,53 +10367,55 @@ ] }, { - "id": "pr-issue-comment-4976149362", + "id": "pr-issue-comment-4976059665", "repo": "opentelemetry-python-genai", "pull_request": 247, - "requester": "lmolkova", + "requester": "eternalcuriouslearner", "pr_author": "123liuziming", "review_state": null, - "body": "@eternalcuriouslearner it's not a super-strong opinion, but I'd prefer to have minimal viable instrumentation in one PR. \r\n\r\n1. It allows us to simplify migration for openinference and other instrumentations\r\n2. it prevents shell instrumentations we have today (weaviate, claude agents sdk)\r\n3. My mental load is actually lower when I look at everything at once\r\n4. Given that instrumentation code in the library is super-thin and leverages util-genai, it's easy to review\r\n5. We'll improve these over time, conformance and general safety is the top priority for me at the moment.", + "root_timestamp": "2026-07-15T01:48:49Z", + "body": "@lmolkova do you think we should separate this into two PRs like say:\n\n1. Basic setup(examples, gh, lint and other setup) for agent scope like we did in python contrib.\n2. Add all the instrumentation as this is a donation.\n\nThis might basically reduce the cognitive load on reviewers. Wdyt?", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", + "no_author_action", + "author_action", "author_action", + "author_action" + ], + "run_labels": [ "no_author_action", "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-issue-comment-5054317690", + "id": "pr-issue-comment-4976149362", "repo": "opentelemetry-python-genai", "pull_request": 247, - "requester": "AgentGymLeader", + "requester": "lmolkova", "pr_author": "123liuziming", "review_state": null, - "body": "Ran into one concrete case of this while looking at the native extractor recently: gen_ai.response.finish_reasons is hardcoded as the JSON string '[\"stop\"]' (with a FIXME) where the registry type is string[] — https://github.com/agentscope-ai/agentscope/blob/7af58b119bddeb42b12d8d93460d424fad253234/src/agentscope/middleware/_tracing/_extractor.py#L337-L339", + "root_timestamp": "2026-07-15T02:06:40Z", + "body": "@eternalcuriouslearner it's not a super-strong opinion, but I'd prefer to have minimal viable instrumentation in one PR. \r\n\r\n1. It allows us to simplify migration for openinference and other instrumentations\r\n2. it prevents shell instrumentations we have today (weaviate, claude agents sdk)\r\n3. My mental load is actually lower when I look at everything at once\r\n4. Given that instrumentation code in the library is super-thin and leverages util-genai, it's easy to review\r\n5. We'll improve these over time, conformance and general safety is the top priority for me at the moment.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", + "no_author_action", "no_author_action", "no_author_action", "no_author_action", @@ -9897,23 +10423,24 @@ ] }, { - "id": "pr-issue-comment-5054482096", + "id": "pr-review-4739968589", "repo": "opentelemetry-python-genai", "pull_request": 247, "requester": "lmolkova", "pr_author": "123liuziming", - "review_state": null, - "body": "@123liuziming @AgentGymLeader we should try checking if AgentScope authors would be open to contributions before moving on with instrumentation here.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-21T00:12:21Z", + "body": "it seems agentscope comes with native otel instrumentation (but in a broken way since it depends on the exporter) - do we know if instrumentation is good? does it follow conventions? \n\nSince there is an existing instrumentation, we should not invent another one. Was there an attempt to contribute directly to https://github.com/agentscope-ai/agentscope if there any gaps?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9924,48 +10451,52 @@ ] }, { - "id": "pr-review-4698657099", + "id": "pr-issue-comment-5054317690", "repo": "opentelemetry-python-genai", "pull_request": 247, - "requester": "lmolkova", + "requester": "AgentGymLeader", "pr_author": "123liuziming", - "review_state": "COMMENTED", - "body": "LGTM, just some minor questions and concerns around build and release", - "role": "context", - "stability": null, - "recorded_label": null, + "review_state": null, + "root_timestamp": "2026-07-23T04:24:44Z", + "body": "Ran into one concrete case of this while looking at the native extractor recently: gen_ai.response.finish_reasons is hardcoded as the JSON string '[\"stop\"]' (with a FIXME) where the registry type is string[] — https://github.com/agentscope-ai/agentscope/blob/7af58b119bddeb42b12d8d93460d424fad253234/src/agentscope/middleware/_tracing/_extractor.py#L337-L339", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - null, - "author", - "none", - null, - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-4739968589", + "id": "pr-issue-comment-5054482096", "repo": "opentelemetry-python-genai", "pull_request": 247, "requester": "lmolkova", "pr_author": "123liuziming", - "review_state": "CHANGES_REQUESTED", - "body": "it seems agentscope comes with native otel instrumentation (but in a broken way since it depends on the exporter) - do we know if instrumentation is good? does it follow conventions? \n\nSince there is an existing instrumentation, we should not invent another one. Was there an attempt to contribute directly to https://github.com/agentscope-ai/agentscope if there any gaps?", + "review_state": null, + "root_timestamp": "2026-07-23T04:43:38Z", + "body": "@123liuziming @AgentGymLeader we should try checking if AgentScope authors would be open to contributions before moving on with instrumentation here.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -9982,17 +10513,18 @@ "requester": "Nik-Reddy", "pr_author": "lmolkova", "review_state": null, + "root_timestamp": "2026-07-15T22:49:34Z", "body": "Thanks for picking this up @lmolkova! I'm glad to see the streaming timing work from my original PR #13 moving forward. Happy to review this since I worked on the initial implementation.\n\nAlso happy to co-author this if it helps, since a lot of the design decisions here came out of the iteration on #13. Let me know!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10009,17 +10541,18 @@ "requester": "lmolkova", "pr_author": "rads-1996", "review_state": "APPROVED", + "root_timestamp": "2026-07-25T19:05:31Z", "body": "Couple of questions and minor comment to change tests to be more realistic, looks good otherwise!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10036,17 +10569,18 @@ "requester": "eternalcuriouslearner", "pr_author": "royrhea", "review_state": "COMMENTED", + "root_timestamp": "2026-07-27T12:48:39Z", "body": "Thanks a lot for your contribution. Couple of things:\n\n1. Can you please check if groq has native instrumentation?\n2. If yes, can you see if they're emitting genai spans or not.\n3. After this analysis can you please cut down the verbosity of this pr? You can space it like: skeleton, inference spans, agent spans etc. For now if you don't mind can you please close this pr and first let me know if 1 & 2 are not in place before we proceed adding the telemetry support.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10063,17 +10597,18 @@ "requester": "AgentGymLeader", "pr_author": "srinjoy356", "review_state": null, + "root_timestamp": "2026-07-27T11:15:53Z", "body": "@srinjoy356 the `README.rst` and several modules point readers at `MIGRATION_REPORT.md` for the gap list, but that filename is excluded by the root `.gitignore` (\"Migration review reports generated by the review-migration skill\"), and it isn't in this PR's head or anywhere else in the tree.\n\nSince `README.rst` becomes the PyPI description, that leaves a dangling pointer for anyone installing the package. Dropping the references, or folding the parts readers need into the README itself, would probably be cleaner than pointing at a file that by design never gets committed.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10090,17 +10625,18 @@ "requester": "AgentGymLeader", "pr_author": "srinjoy356", "review_state": null, + "root_timestamp": "2026-07-27T11:33:41Z", "body": "@srinjoy356 checked 647446e — the references are gone from the package and the Known limitations section reads well on its own. Thanks for turning it around so fast.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10117,17 +10653,18 @@ "requester": "eternalcuriouslearner", "pr_author": "srinjoy356", "review_state": "COMMENTED", + "root_timestamp": "2026-07-27T12:47:14Z", "body": "Thanks a lot for your contribution @srinjoy356. Couple of things:\n\n1. Can you please check if haystack has native instrumentation?\n2. If yes, can you see if they're emitting genai spans or not.\n3. After this analysis can you please cut down the verbosity of this pr? You can space it like: skeleton, inference spans, agent spans etc. For now if you don't mind can you please close this pr and first let me know if 1 & 2 are not in place before we proceed adding the telemetry support.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10144,25 +10681,26 @@ "requester": "lmolkova", "pr_author": "ahmadalguydi", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-28T19:04:25Z", "body": "This seems to be a duplicate of #24\n\nA more generic solution to this problem is coming via https://github.com/open-telemetry/opentelemetry-specification/pull/4931\n\nIn the current scope this problem can be solved with custom context key and custom log record processor which would be a recommended approach until context-scoped attributes land in OTel spec and python implementation. \n\nIs there a strong use-case to stamp information on events only and avoid spans?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] }, { "id": "pr-issue-comment-5108853441", @@ -10171,17 +10709,18 @@ "requester": "lmolkova", "pr_author": "DylanRussell", "review_state": null, + "root_timestamp": "2026-07-28T19:39:14Z", "body": "> > According to the official OpenTelemetry GenAI Semantic Conventions (0.65b0), gen_ai.tool.definitions is only defined on inference/chat spans (chat, text_completion), not on agent invocation (invoke_agent) spans.\r\n> \r\n> This seems wrong -- why can't tool definitions be on invoke agent spans ? You can define tools on an agent\r\n\r\nwhere did it come from? let's fix, I agree it's wrong", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10198,17 +10737,18 @@ "requester": "svrnm", "pr_author": "maestro24", "review_state": null, + "root_timestamp": "2026-07-13T08:22:47Z", "body": "@maestro24 when you sign the CLA we can review the PR, thanks", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10225,17 +10765,18 @@ "requester": "chalin", "pr_author": "maestro24", "review_state": null, + "root_timestamp": "2026-07-23T14:31:33Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10252,17 +10793,18 @@ "requester": "vitorvasc", "pr_author": "jraleigh", "review_state": null, + "root_timestamp": "2026-07-28T05:07:22Z", "body": "Hi @jraleigh, could you run the `npm run fix:link-cache` script locally and commit the results?\r\n\r\nIt looks like the maintainers don't have permission to push changes to this PR.\r\n\r\nThanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10279,17 +10821,18 @@ "requester": "vitorvasc", "pr_author": "Goran-n", "review_state": null, + "root_timestamp": "2026-07-16T06:24:26Z", "body": "Hi @Goran-n, could you please review and sign the CLA? Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10306,23 +10849,24 @@ "requester": "svrnm", "pr_author": "Goran-n", "review_state": null, + "root_timestamp": "2026-07-18T18:42:32Z", "body": "what @vitorvasc said re CLA, but this is also a vendor not an application integration", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action", "author_action" ] }, @@ -10333,44 +10877,18 @@ "requester": "chalin", "pr_author": "Goran-n", "review_state": null, + "root_timestamp": "2026-07-23T14:31:36Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-5059648393", - "repo": "opentelemetry.io", - "pull_request": 10814, - "requester": "chalin", - "pr_author": "cijothomas", - "review_state": null, - "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -10387,44 +10905,46 @@ "requester": "reyang", "pr_author": "cijothomas", "review_state": "APPROVED", + "root_timestamp": "2026-07-17T22:23:19Z", "body": "I like where this is heading towards. However, I do have several questions about the terminology and whether the statements are precise or confusing. I don't see these as blockers though.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ "author_action", "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-issue-comment-5059649344", + "id": "pr-issue-comment-5059648393", "repo": "opentelemetry.io", - "pull_request": 10829, + "pull_request": 10814, "requester": "chalin", - "pr_author": "fractalwrench", + "pr_author": "cijothomas", "review_state": null, + "root_timestamp": "2026-07-23T14:31:39Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10441,17 +10961,18 @@ "requester": "bidetofevil", "pr_author": "fractalwrench", "review_state": "APPROVED", + "root_timestamp": "2026-07-23T05:27:14Z", "body": "LGTM", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10461,6 +10982,34 @@ "no_author_action" ] }, + { + "id": "pr-issue-comment-5059649344", + "repo": "opentelemetry.io", + "pull_request": 10829, + "requester": "chalin", + "pr_author": "fractalwrench", + "review_state": null, + "root_timestamp": "2026-07-23T14:31:44Z", + "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-review-4776152729", "repo": "opentelemetry.io", @@ -10468,17 +11017,18 @@ "requester": "chalin", "pr_author": "fractalwrench", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-24T19:29:09Z", "body": "Thanks @fractalwrench! I've updated the branch over the latest `main`. One alert-syntax fix needed (suggestion below), then this is good to go from the docs side.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10495,17 +11045,18 @@ "requester": "chalin", "pr_author": "jaydeluca", "review_state": null, + "root_timestamp": "2026-07-23T14:31:52Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10522,17 +11073,18 @@ "requester": "theletterf", "pr_author": "Babul422", "review_state": null, + "root_timestamp": "2026-07-17T14:48:17Z", "body": "This seems to fix the issue, @chalin\r\n\r\n\"Screenshot", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10543,50 +11095,24 @@ ] }, { - "id": "pr-issue-comment-5059651235", + "id": "pr-review-4728369464", "repo": "opentelemetry.io", "pull_request": 10864, "requester": "chalin", "pr_author": "Babul422", - "review_state": null, - "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-18T11:05:28Z", + "body": "- Thanks, I'll take a look soon.\n- @Babul422 please answer the questions added to the opening comment of the PR.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4728369464", - "repo": "opentelemetry.io", - "pull_request": 10864, - "requester": "chalin", - "pr_author": "Babul422", - "review_state": "CHANGES_REQUESTED", - "body": "- Thanks, I'll take a look soon.\n- @Babul422 please answer the questions added to the opening comment of the PR.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -10597,23 +11123,24 @@ ] }, { - "id": "pr-issue-comment-5059652322", + "id": "pr-issue-comment-5059651235", "repo": "opentelemetry.io", - "pull_request": 10879, + "pull_request": 10864, "requester": "chalin", - "pr_author": "thompson-tomo", + "pr_author": "Babul422", "review_state": null, + "root_timestamp": "2026-07-23T14:31:55Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10630,17 +11157,18 @@ "requester": "ymotongpoo", "pr_author": "thompson-tomo", "review_state": "APPROVED", + "root_timestamp": "2026-07-21T13:19:33Z", "body": "LGTM to ja docs", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10650,6 +11178,34 @@ "no_author_action" ] }, + { + "id": "pr-issue-comment-5059652322", + "repo": "opentelemetry.io", + "pull_request": 10879, + "requester": "chalin", + "pr_author": "thompson-tomo", + "review_state": null, + "root_timestamp": "2026-07-23T14:32:01Z", + "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-5059652796", "repo": "opentelemetry.io", @@ -10657,17 +11213,18 @@ "requester": "chalin", "pr_author": "mwimpelberg28", "review_state": null, + "root_timestamp": "2026-07-23T14:32:04Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10684,17 +11241,18 @@ "requester": "immavalls", "pr_author": "mwimpelberg28", "review_state": null, + "root_timestamp": "2026-07-27T10:41:10Z", "body": "Will do today, thanks @mwimpelberg28 🙏🏻", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10711,51 +11269,25 @@ "requester": "immavalls", "pr_author": "mwimpelberg28", "review_state": "APPROVED", + "root_timestamp": "2026-07-27T11:49:34Z", "body": "Thanks @mwimpelberg28, looking great, just a few small suggestions, feel free to accept them or not. Except the `lock-in`, which I would not call bloque in Spanish, and the fediverse being fediverso, the rest is up to your taste.", "role": "scored", "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" - ] - }, - { - "id": "pr-issue-comment-5059653748", - "repo": "opentelemetry.io", - "pull_request": 10894, - "requester": "chalin", - "pr_author": "ymotongpoo", - "review_state": null, - "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -10765,18 +11297,19 @@ "requester": "katzchang", "pr_author": "ymotongpoo", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-21T09:00:13Z", "body": "1箇所、リンクの箇所だけコメントしました。\n\n本文は完璧です。", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], "run_labels": [ "no_author_action", "no_author_action", @@ -10785,6 +11318,34 @@ "no_author_action" ] }, + { + "id": "pr-issue-comment-5059653748", + "repo": "opentelemetry.io", + "pull_request": 10894, + "requester": "chalin", + "pr_author": "ymotongpoo", + "review_state": null, + "root_timestamp": "2026-07-23T14:32:10Z", + "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-5059654246", "repo": "opentelemetry.io", @@ -10792,17 +11353,18 @@ "requester": "chalin", "pr_author": "manduinca", "review_state": null, + "root_timestamp": "2026-07-23T14:32:12Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10819,17 +11381,18 @@ "requester": "immavalls", "pr_author": "manduinca", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-27T12:11:46Z", "body": "Kindly correct the links on all sections, the rest LGTM, thanks @manduinca 🎉", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10846,17 +11409,18 @@ "requester": "chalin", "pr_author": "cxdy", "review_state": null, + "root_timestamp": "2026-07-23T14:26:00Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10873,17 +11437,18 @@ "requester": "vitorvasc", "pr_author": "cxdy", "review_state": null, + "root_timestamp": "2026-07-28T05:09:03Z", "body": "Hi @cxdy, could you run the `npm run fix:link-cache` script locally and commit the results?\r\n\r\nThanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10900,17 +11465,18 @@ "requester": "vitorvasc", "pr_author": "cxdy", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T05:56:05Z", "body": "@cxdy, thanks!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -10927,17 +11493,18 @@ "requester": "svrnm", "pr_author": "snowmen233", "review_state": null, + "root_timestamp": "2026-07-21T07:07:34Z", "body": "@snowmen233 please make sure you sign the CLA otherwise we can not accept the PR. Thank you.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10954,17 +11521,18 @@ "requester": "chalin", "pr_author": "snowmen233", "review_state": null, + "root_timestamp": "2026-07-23T14:25:47Z", "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -10981,23 +11549,23 @@ "requester": "svrnm", "pr_author": "intuibase", "review_state": null, + "root_timestamp": "2026-07-22T13:33:24Z", "body": "@SergeyKleyman as second maintainer of the distro, can you please do a technical review and give us a thumbs up or down. After this PR is merged we can do the infra changes such that @open-telemetry/php-distro-approvers has ownership of these files.", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "role": "context", + "stability": null, + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + null, + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", "no_author_action" ] }, @@ -11008,44 +11576,45 @@ "requester": "ymotongpoo", "pr_author": "intuibase", "review_state": "APPROVED", + "root_timestamp": "2026-07-22T14:10:31Z", "body": "LGTM for JA part", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "role": "context", + "stability": null, + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + null, + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", "no_author_action" ] }, { - "id": "pr-issue-comment-5059225256", + "id": "pr-review-4756196809", "repo": "opentelemetry.io", "pull_request": 10959, "requester": "chalin", "pr_author": "svrnm", - "review_state": null, - "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-22T15:49:37Z", + "body": "I reviewed with copilot, here's it's main comment when I asked to ensure completeness per our repo's ownership conventions:\r\n\r\n> The new child mappings overlap the existing content/en/docs/zero-code/go ownership and label rules. Our component-owner logic accumulates every prefix match, and the labeler applies every matching glob, so compile-time PRs will still involve go-approvers and go-instrumentation-approvers and receive both SIG labels. Please adjust the parent mappings so the compile-time subtree is excluded or otherwise represented without overlapping ownership.\r\n\r\nOf course, the shared ownership might have been intentional. Pls clarify.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11056,57 +11625,59 @@ ] }, { - "id": "pr-issue-comment-5059287828", + "id": "pr-issue-comment-5059225256", "repo": "opentelemetry.io", "pull_request": 10959, "requester": "chalin", "pr_author": "svrnm", "review_state": null, - "body": "(I've done the rebase :)", + "root_timestamp": "2026-07-23T13:52:58Z", + "body": "👋 Please update this PR's branch over the latest `main`: it predates our link-checker [switch to Lychee][#10911] and can hit CI failures unrelated to your changes. For the how — including conflicts and after-update steps — see [#10990][]. Thanks for your contribution!\n\n[#10911]: https://github.com/open-telemetry/opentelemetry.io/pull/10911\n[#10990]: https://github.com/open-telemetry/opentelemetry.io/issues/10990", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { - "id": "pr-review-4756196809", + "id": "pr-issue-comment-5059287828", "repo": "opentelemetry.io", "pull_request": 10959, "requester": "chalin", "pr_author": "svrnm", - "review_state": "CHANGES_REQUESTED", - "body": "I reviewed with copilot, here's it's main comment when I asked to ensure completeness per our repo's ownership conventions:\r\n\r\n> The new child mappings overlap the existing content/en/docs/zero-code/go ownership and label rules. Our component-owner logic accumulates every prefix match, and the labeler applies every matching glob, so compile-time PRs will still involve go-approvers and go-instrumentation-approvers and receive both SIG labels. Please adjust the parent mappings so the compile-time subtree is excluded or otherwise represented without overlapping ownership.\r\n\r\nOf course, the shared ownership might have been intentional. Pls clarify.", + "review_state": null, + "root_timestamp": "2026-07-23T13:58:54Z", + "body": "(I've done the rebase :)", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -11116,17 +11687,18 @@ "requester": "didiViking", "pr_author": "viorel-alexandrescu", "review_state": null, + "root_timestamp": "2026-07-28T02:14:03Z", "body": "@IrinaKarantoniou @dnanuti @elifsamedin Please add your reviews. Thanks!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11143,17 +11715,18 @@ "requester": "kohbis", "pr_author": "ymotongpoo", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T12:16:57Z", "body": "LGTM ✅", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11170,17 +11743,18 @@ "requester": "vitorvasc", "pr_author": "arthi-arumugam-git", "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T05:09:59Z", "body": "Could you also run the `npm run fix:link-cache` script locally and commit the results?\n\nThanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11197,17 +11771,18 @@ "requester": "julianocosta89", "pr_author": "mwimpelberg28", "review_state": null, + "root_timestamp": "2026-07-27T05:30:41Z", "body": "@mwimpelberg28 I believe the `co-authored` added by Claude messed up the EasyCLA.\r\nIt should be `assisted by` instead.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11224,17 +11799,18 @@ "requester": "kota-sakuma", "pr_author": "ymotongpoo", "review_state": "APPROVED", + "root_timestamp": "2026-07-27T04:41:53Z", "body": "LGTM!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11251,17 +11827,18 @@ "requester": "kota-sakuma", "pr_author": "ymotongpoo", "review_state": "APPROVED", + "root_timestamp": "2026-07-27T04:39:31Z", "body": "LGTM!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11278,17 +11855,18 @@ "requester": "kota-sakuma", "pr_author": "ymotongpoo", "review_state": "APPROVED", + "root_timestamp": "2026-07-27T04:29:18Z", "body": "LGTM!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11305,17 +11883,18 @@ "requester": "kota-sakuma", "pr_author": "ymotongpoo", "review_state": "APPROVED", + "root_timestamp": "2026-07-27T04:31:19Z", "body": "LGTM!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11332,24 +11911,25 @@ "requester": "jmacd", "pr_author": "cijothomas", "review_state": "APPROVED", + "root_timestamp": "2026-07-08T15:30:32Z", "body": "Thanks for pushing this through, and for the register-once fix. Reusing the signal streams across both waits is the right call to avoid dropping a second signal during the drain.\n\nOn the outstanding copilot-reviewer note about the dropped `JoinHandle`, I don't think it's a problem. In Rust the process terminates when `main` returns, and the detached signal-handler thread is reaped at that point rather than keeping the process alive. It would only block exit if something joined it, and nothing does. Your code comments already capture this, so I'm comfortable leaving the thread detached.\n\nThe double-signal convention matches the Go Collector, and a 60s drain deadline aligned with the default Kubernetes `terminationGracePeriodSeconds` is a sensible default. LGTM.\n\nOne optional and non-blocking follow-up: patch coverage on the new signal paths is on the lighter side, so a small test exercising the second-signal force-exit path would be welcome if it is easy to add.", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -11359,21 +11939,22 @@ "requester": "jmacd", "pr_author": "ThomsonTan", "review_state": null, + "root_timestamp": "2026-07-20T20:36:22Z", "body": "@drewrelmas should we update this PR to reflect the progress in https://github.com/open-telemetry/otel-arrow/pull/3454?", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "no_author_action", + "author_action", "no_author_action", "no_author_action", "no_author_action" @@ -11386,17 +11967,18 @@ "requester": "drewrelmas", "pr_author": "ThomsonTan", "review_state": null, + "root_timestamp": "2026-07-20T21:17:00Z", "body": "Yes - @ThomsonTan could you please take a look at https://github.com/open-telemetry/otel-arrow/blob/main/rust/otap-dataflow/docs/telemetry/item-attributes.md and update this implementation accordingly?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11407,50 +11989,24 @@ ] }, { - "id": "pr-issue-comment-5027596016", + "id": "pr-review-4601840364", "repo": "otel-arrow", "pull_request": 3317, - "requester": "jmacd", + "requester": "lquerel", "pr_author": "lalitb", - "review_state": null, - "body": "Note there is a heavy discussion about how to package eBPF artifacts for Collector.\r\n\r\nhttps://github.com/open-telemetry/opentelemetry-collector/issues/15430#issuecomment-4907834085", + "review_state": "COMMENTED", + "root_timestamp": "2026-06-30T16:03:32Z", + "body": "I'm looking forward to seeing this proposal implemented!\n\nI haven't finished my review yet, but I'd rather send this first batch of feedback now and continue as soon as possible, probably tomorrow.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4601840364", - "repo": "otel-arrow", - "pull_request": 3317, - "requester": "lquerel", - "pr_author": "lalitb", - "review_state": "COMMENTED", - "body": "I'm looking forward to seeing this proposal implemented!\n\nI haven't finished my review yet, but I'd rather send this first batch of feedback now and continue as soon as possible, probably tomorrow.", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ "no_author_action", @@ -11467,17 +12023,18 @@ "requester": "lquerel", "pr_author": "lalitb", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-01T13:48:16Z", "body": "Thank you, Lalit, for putting together this excellent specification for integrating an eBPF-based load-balancing mechanism with `SO_REUSEPORT` socket groups.\n\nMy main comment is that we should split this document into two parts: one focused on NUMA discovery (see one of my comment), and the other on eBPF load balancing.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11487,6 +12044,34 @@ "author_action" ] }, + { + "id": "pr-issue-comment-5027596016", + "repo": "otel-arrow", + "pull_request": 3317, + "requester": "jmacd", + "pr_author": "lalitb", + "review_state": null, + "root_timestamp": "2026-07-20T21:46:01Z", + "body": "Note there is a heavy discussion about how to package eBPF artifacts for Collector.\r\n\r\nhttps://github.com/open-telemetry/opentelemetry-collector/issues/15430#issuecomment-4907834085", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, { "id": "pr-review-4739211941", "repo": "otel-arrow", @@ -11494,17 +12079,18 @@ "requester": "jmacd", "pr_author": "drewrelmas", "review_state": "COMMENTED", + "root_timestamp": "2026-07-20T21:42:23Z", "body": "Looks good. @lquerel should have a look at synchronization primitives, the Mutex. Note we merged https://github.com/open-telemetry/otel-arrow/pull/3323 as a foundation for this.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11521,17 +12107,18 @@ "requester": "lalitb", "pr_author": "timr-dev", "review_state": null, + "root_timestamp": "2026-06-29T16:14:24Z", "body": "Nit: Can we update `rust/otap-dataflow/docs/memory-limiter-phase1.md` too? The “Receiver Behavior Under Hard Pressure” section still says Soft never rejects, but with `soft_action: shed`, Soft can now use the same receiver shedding behavior in `enforce` mode.\r\n\r\nAlso, should we rename `memory-limiter-phase1.md` to something like `global-memory-limiter.md` and replace the “Phase 1” wording in the title/intro with “global/ process-wide memory limiter”? This PR still changes the global limiter, while the retained-work budgeting / tenant/group isolation direction is tracked separately in #3272. A behavior-based doc name may avoid Phase 1/Phase 2 confusion as both efforts evolve.\r\n\r\nFor the same reason, could we also reword “Phase 2 of the process-wide memory limiter” in the PR description? Maybe “follow-up to the process-wide memory limiter” would be clearer.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11542,131 +12129,136 @@ ] }, { - "id": "pr-issue-comment-4846411522", + "id": "pr-review-4593499556", "repo": "otel-arrow", "pull_request": 3363, "requester": "lalitb", "pr_author": "timr-dev", - "review_state": null, - "body": "> Rename memory-limiter-phase1.md → global-memory-limiter.md + drop the \"Phase 1\" wording — I'd prefer to keep this out of this PR and do it as a dedicated follow-up. The rename touches cross-references in docs/configuration.md (which this PR otherwise doesn't change), and the \"Phase 1 → global / process-wide\" reframing is really part of the naming evolution tracked in https://github.com/open-telemetry/otel-arrow/issues/3272, so it reads cleaner as its own focused change than mixing a doc-wide rename into the soft_action feature PR. I'm happy to open that follow-up right after this merges — target name global-memory-limiter.md, intro reworded to \"global / process-wide memory limiter\". Let me know if you'd rather I bundle it here instead.\r\n\r\nAgree on this.", + "review_state": "APPROVED", + "root_timestamp": "2026-06-29T16:15:05Z", + "body": "Thanks. LGTM. Good to have doc update before merge.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "none", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", - "author_action", "no_author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-issue-comment-4937419302", + "id": "pr-issue-comment-4846411522", "repo": "otel-arrow", "pull_request": 3363, "requester": "lalitb", "pr_author": "timr-dev", "review_state": null, - "body": "> @lalit During the review of this PR, I noticed a few things related to a previous PR on the memory limiter side that seemed suboptimal. I'll file a separate report for those.\r\n\r\nSure @lquerel. Thanks for reviewing that part. Will look forward to your findings.", + "root_timestamp": "2026-06-30T17:52:49Z", + "body": "> Rename memory-limiter-phase1.md → global-memory-limiter.md + drop the \"Phase 1\" wording — I'd prefer to keep this out of this PR and do it as a dedicated follow-up. The rename touches cross-references in docs/configuration.md (which this PR otherwise doesn't change), and the \"Phase 1 → global / process-wide\" reframing is really part of the naming evolution tracked in https://github.com/open-telemetry/otel-arrow/issues/3272, so it reads cleaner as its own focused change than mixing a doc-wide rename into the soft_action feature PR. I'm happy to open that follow-up right after this merges — target name global-memory-limiter.md, intro reworded to \"global / process-wide memory limiter\". Let me know if you'd rather I bundle it here instead.\r\n\r\nAgree on this.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", + "author_action", "no_author_action" ] }, { - "id": "pr-issue-comment-4963445519", + "id": "pr-review-4666073835", "repo": "otel-arrow", "pull_request": 3363, - "requester": "lalitb", + "requester": "jmacd", "pr_author": "timr-dev", - "review_state": null, - "body": "> > @lalit During the review of this PR, I noticed a few things related to a previous PR on the memory limiter side that seemed suboptimal. I'll file a separate report for those.\r\n> \r\n> Sure @lquerel. Thanks for reviewing that part. Will look forward to your findings.\r\n\r\n@lquerel - I dug a bit more into the memory limiter after your comment. \r\n\r\nThe [docs](https://github.com/open-telemetry/otel-arrow/blob/main/rust/otap-dataflow/docs/memory-limiter-phase1.md#tradeoffs) describe the mechanics: sampling is periodic and enforcement happens only at ingress when the state reaches `Hard`. So the limitation is mostly implied rather than stated directly: this can reduce new memory growth, but it is not a strict cap and it cannot immediately reclaim memory already held inside the process.\r\n\r\n The real issues I found are more specific:\r\n\r\n - The default hysteresis is derived from the soft-to-hard gap and can become very large. With a wide gap, `Soft` can become sticky because memory must fall far below the soft limit to return to `Normal`. This mainly affects state reporting today because `Soft` does not reject ingress.\r\n - `source: auto` only checks the current/leaf cgroup limit. In nes ...[truncated]", + "review_state": "APPROVED", + "root_timestamp": "2026-07-09T19:19:36Z", + "body": "Reviewed critically and validated locally (checked out the branch, ran targeted tests + compiled the new bench). Approving — everything below is non-blocking.\n\n## Validation\n\n- `config` 66 passed, `engine::memory_limiter` 24 passed (incl. all 8 new), `memory_admission` bench compiles, clippy clean on `config`.\n- All three `should_shed_ingress()` sites and every ingress consumer (otlp/otap/syslog_cef/user_events receivers + the tower layer) route through the new predicate; no stray `== Hard` shed comparisons remain.\n- `soft_action` propagation mirrors the existing `mode` pattern exactly (atomic on the process inner, plain field on receiver inners), and `configure()` runs before receivers snapshot.\n- Default path is byte-identical (`shed_decision(_, _, Observe)` == old `Enforce && Hard`). Hysteresis is sound: with `soft_action: shed`, the existing Soft→Normal reopen threshold (`soft_limit − hysteresis`) becomes the shed-reopen point, so no oscillation.\n- Doc sweep is thorough — grepped untouched receiver `.rs`/README files for stale \"Soft is informational / Hard-only\" wording; none remain.\n\n## Non-blocking notes\n\n1. **Process-wide `MemoryPressureState::should_shed_ingress()` has no p ...[truncated]", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-issue-comment-5049650420", + "id": "pr-review-4668488884", "repo": "otel-arrow", "pull_request": 3363, - "requester": "lalitb", + "requester": "lquerel", "pr_author": "timr-dev", - "review_state": null, - "body": "@timr-dev - One context update since this PR was first opened: while you were out, #3484 landed the pressure-aware rate throttling design, and #3529 is now implementing that path. That design uses Soft pressure as the trigger for selective receiver-local throttling, where over-rate scopes are throttled while within-rate scopes continue.\r\n\r\nGiven that newer direction, should we still keep `soft_action: shed` in this PR as a separate global Soft-pressure emergency mode? Or should this PR avoid adding that behavior now, and leave Soft-pressure throttling to the #3529 rate-throttling implementation? I realize this may mean some rework, but I think it is worth checking now so we do not land two overlapping Soft-pressure control models.", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-10T04:54:39Z", + "body": "@timr-dev Overall, this looks good to me. I think there's a small issue in the logic around the soft/hard limits combined with hysteresis.\n\n@lalit During the review of this PR, I noticed a few things related to a previous PR on the memory limiter side that seemed suboptimal. I'll file a separate report for those.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", + "no_author_action", "author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ "author_action", + "no_author_action", "author_action", - "author_action" + "no_author_action", + "no_author_action" ] }, { - "id": "pr-review-4593499556", + "id": "pr-issue-comment-4937419302", "repo": "otel-arrow", "pull_request": 3363, "requester": "lalitb", "pr_author": "timr-dev", - "review_state": "APPROVED", - "body": "Thanks. LGTM. Good to have doc update before merge.", + "review_state": null, + "root_timestamp": "2026-07-10T16:31:52Z", + "body": "> @lalit During the review of this PR, I noticed a few things related to a previous PR on the memory limiter side that seemed suboptimal. I'll file a separate report for those.\r\n\r\nSure @lquerel. Thanks for reviewing that part. Will look forward to your findings.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11677,47 +12269,52 @@ ] }, { - "id": "pr-review-4666073835", + "id": "pr-issue-comment-4963445519", "repo": "otel-arrow", "pull_request": 3363, - "requester": "jmacd", + "requester": "lalitb", "pr_author": "timr-dev", - "review_state": "APPROVED", - "body": "Reviewed critically and validated locally (checked out the branch, ran targeted tests + compiled the new bench). Approving — everything below is non-blocking.\n\n## Validation\n\n- `config` 66 passed, `engine::memory_limiter` 24 passed (incl. all 8 new), `memory_admission` bench compiles, clippy clean on `config`.\n- All three `should_shed_ingress()` sites and every ingress consumer (otlp/otap/syslog_cef/user_events receivers + the tower layer) route through the new predicate; no stray `== Hard` shed comparisons remain.\n- `soft_action` propagation mirrors the existing `mode` pattern exactly (atomic on the process inner, plain field on receiver inners), and `configure()` runs before receivers snapshot.\n- Default path is byte-identical (`shed_decision(_, _, Observe)` == old `Enforce && Hard`). Hysteresis is sound: with `soft_action: shed`, the existing Soft→Normal reopen threshold (`soft_limit − hysteresis`) becomes the shed-reopen point, so no oscillation.\n- Doc sweep is thorough — grepped untouched receiver `.rs`/README files for stale \"Soft is informational / Hard-only\" wording; none remain.\n\n## Non-blocking notes\n\n1. **Process-wide `MemoryPressureState::should_shed_ingress()` has no p ...[truncated]", - "role": "context", - "stability": null, - "recorded_label": null, + "review_state": null, + "root_timestamp": "2026-07-13T22:35:54Z", + "body": "> > @lalit During the review of this PR, I noticed a few things related to a previous PR on the memory limiter side that seemed suboptimal. I'll file a separate report for those.\r\n> \r\n> Sure @lquerel. Thanks for reviewing that part. Will look forward to your findings.\r\n\r\n@lquerel - I dug a bit more into the memory limiter after your comment. \r\n\r\nThe [docs](https://github.com/open-telemetry/otel-arrow/blob/main/rust/otap-dataflow/docs/memory-limiter-phase1.md#tradeoffs) describe the mechanics: sampling is periodic and enforcement happens only at ingress when the state reaches `Hard`. So the limitation is mostly implied rather than stated directly: this can reduce new memory growth, but it is not a strict cap and it cannot immediately reclaim memory already held inside the process.\r\n\r\n The real issues I found are more specific:\r\n\r\n - The default hysteresis is derived from the soft-to-hard gap and can become very large. With a wide gap, `Soft` can become sticky because memory must fall far below the soft limit to return to `Normal`. This mainly affects state reporting today because `Soft` does not reject ingress.\r\n - `source: auto` only checks the current/leaf cgroup limit. In nes ...[truncated]", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - null, - null, - "author", - null + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ + "author_action", + "author_action", + "author_action", "author_action", "author_action" ] }, { - "id": "pr-review-4668488884", + "id": "pr-issue-comment-5049650420", "repo": "otel-arrow", "pull_request": 3363, - "requester": "lquerel", + "requester": "lalitb", "pr_author": "timr-dev", - "review_state": "COMMENTED", - "body": "@timr-dev Overall, this looks good to me. I think there's a small issue in the logic around the soft/hard limits combined with hysteresis.\n\n@lalit During the review of this PR, I noticed a few things related to a previous PR on the memory limiter side that seemed suboptimal. I'll file a separate report for those.", + "review_state": null, + "root_timestamp": "2026-07-22T18:02:18Z", + "body": "@timr-dev - One context update since this PR was first opened: while you were out, #3484 landed the pressure-aware rate throttling design, and #3529 is now implementing that path. That design uses Soft pressure as the trigger for selective receiver-local throttling, where over-rate scopes are throttled while within-rate scopes continue.\r\n\r\nGiven that newer direction, should we still keep `soft_action: shed` in this PR as a separate global Soft-pressure emergency mode? Or should this PR avoid adding that behavior now, and leave Soft-pressure throttling to the #3529 rate-throttling implementation? I realize this may mean some rework, but I think it is worth checking now so we do not land two overlapping Soft-pressure control models.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11727,6 +12324,34 @@ "author_action" ] }, + { + "id": "pr-review-4611878448", + "repo": "otel-arrow", + "pull_request": 3374, + "requester": "jmacd", + "pr_author": "AvinashDevX", + "review_state": "APPROVED", + "root_timestamp": "2026-07-01T18:19:27Z", + "body": "Looks good to me. @lalitb please take another look.\nThanks @AvinashDevX.", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" + ] + }, { "id": "pr-issue-comment-4858861424", "repo": "otel-arrow", @@ -11734,17 +12359,18 @@ "requester": "jmacd", "pr_author": "AvinashDevX", "review_state": null, + "root_timestamp": "2026-07-01T18:20:04Z", "body": "@AvinashDevX how would you feel setting the default batch size to 64KiB instead of disabled by default?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11761,17 +12387,18 @@ "requester": "jmacd", "pr_author": "AvinashDevX", "review_state": null, + "root_timestamp": "2026-07-08T15:22:53Z", "body": "@AvinashDevX thanks for iterating on this. Two items before I merge.\n\n1. Are you still planning to switch `batch_size` from a record count to a byte size defaulting to 64 KiB, as we discussed on July 1? I don't see it in the current diff. I'd like the receiver to batch by default so downstream messages are reasonably sized without extra configuration.\n\n2. Could you confirm the early-return path lalitb flagged in `internal_telemetry_receiver/mod.rs`? His concern is that returning there without flushing can drop up to `threshold - 1` buffered records, and I want to be sure a shutdown or channel close on that branch cannot lose a partial batch. Tests covering the timer-flush and byte-split paths would also help lock this down.\n\nHappy to re-review once those are addressed. Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11788,17 +12415,18 @@ "requester": "drewrelmas", "pr_author": "AvinashDevX", "review_state": null, + "root_timestamp": "2026-07-14T16:02:26Z", "body": "@AvinashDevX this looks good to me - before merging can you please update the PR title and description to denote batching is now on by default for future viewing in Git history?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -11815,51 +12443,25 @@ "requester": "jmacd", "pr_author": "AvinashDevX", "review_state": null, + "root_timestamp": "2026-07-20T22:46:09Z", "body": "@AvinashDevX will you please resolve? Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4611878448", - "repo": "otel-arrow", - "pull_request": 3374, - "requester": "jmacd", - "pr_author": "AvinashDevX", - "review_state": "APPROVED", - "body": "Looks good to me. @lalitb please take another look.\nThanks @AvinashDevX.", - "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", - "adjudicated_label": null, - "run_actions": [ - "none", - "none", - "none", - "none", - "none" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -11869,22 +12471,23 @@ "requester": "drewrelmas", "pr_author": "ethanchewy", "review_state": "COMMENTED", + "root_timestamp": "2026-07-07T22:19:41Z", "body": "Thanks for looking into this change @ethanchewy! Have a few comments below to hopefully future proof this solution.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", - "no_author_action", + "author_action", "no_author_action", "no_author_action" ] @@ -11896,17 +12499,18 @@ "requester": "drewrelmas", "pr_author": "Dipanshusinghh", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T21:12:24Z", "body": "LGTM, left one small maintainability comment", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11923,17 +12527,18 @@ "requester": "lquerel", "pr_author": "yeomin4242", "review_state": null, + "root_timestamp": "2026-07-20T20:14:31Z", "body": "In @albertlockett’s absence, I’d like @JakeDern to review this PR. Thanks", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -11944,76 +12549,80 @@ ] }, { - "id": "pr-issue-comment-5065765015", + "id": "pr-review-4741233658", "repo": "otel-arrow", "pull_request": 3524, "requester": "JakeDern", "pr_author": "yeomin4242", - "review_state": null, - "body": "> > Thank you for working hard on this! I see there have been a lot of iterations between this PR and the previous.\r\n> \r\n> > \r\n> \r\n> > Apologies if this has already been discussed elsewhere, but I'm wondering why the solution is not to call `OtapArrowRecords::decode_transport_optimized_ids` in the various `try_from` implementations? That would be a very small change (3 lines or so) and I think solve the problem.\r\n> \r\n> > \r\n> \r\n> > In my opinion view creation should not fail unless we're seeing data corruption as there's no alternative for a caller in the failure case. This PR seems to take the same opinion, as we have updated all callers to decode before creating the view to avoid it.\r\n> \r\n> > \r\n> \r\n> > I'm wondering then why we're letting callers make the mistake of not decoding in a way that can only be found at runtime instead of proactively doing it in the implementation.\r\n> \r\n> \r\n> \r\n> Thanks for raising this. \r\n> \r\n> \r\n> \r\n> I agree that callers should not have to remember to decode first, and that this error should not normally surface in application code.\r\n> \r\n> \r\n> \r\n> The current TryFrom<&OtapArrowRecords> implementation only has immutable access, whereas decoding require ...[truncated]", - "role": "context", - "stability": null, - "recorded_label": null, + "review_state": "COMMENTED", + "root_timestamp": "2026-07-21T04:54:32Z", + "body": "Thank you for working hard on this! I see there have been a lot of iterations between this PR and the previous.\n\nApologies if this has already been discussed elsewhere, but I'm wondering why the solution is not to call `OtapArrowRecords::decode_transport_optimized_ids` in the various `try_from` implementations? That would be a very small change (3 lines or so) and I think solve the problem.\n\nIn my opinion view creation should not fail unless we're seeing data corruption as there's no alternative for a caller in the failure case. This PR seems to take the same opinion, as we have updated all callers to decode before creating the view to avoid it. \n\nI'm wondering then why we're letting callers make the mistake of not decoding in a way that can only be found at runtime instead of proactively doing it in the implementation.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - null, - "author", - "none", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "no_author_action", + "author_action", + "author_action", "author_action", "author_action" ] }, { - "id": "pr-issue-comment-5099464449", + "id": "pr-issue-comment-5065765015", "repo": "otel-arrow", "pull_request": 3524, "requester": "JakeDern", "pr_author": "yeomin4242", "review_state": null, - "body": "I think we should scope this PR to the main issue, which is preventing the construction of invalid views. The `DecodedOtapLogsResources` construct that the router and validator are using look like an unrelated optimization, as those components were calling the normal `try_from` implementation before this PR. \r\n\r\nBesides the optimizations being unrelated, I'm not sure that the solutions in this PR are the best we can do. For example, having a second `OtapLogsResourcesView` construct that is a subset of the `OtapLogsView` seems like a maintenance burden and complicates the API surface area. I don't have a perfect solution here, but I'll put a couple of ideas at the bottom. \r\n\r\nAdditionally, the benefit of these optimizations is not demonstrated anywhere that I can see and there may not be sufficient impact. For example, I previously considered optimizing the views for the temporal reaggregation processor, but after profiling I did not see significant time spent there. Did you make a different discovery?\r\n\r\nIn short, I think 2000 lines of code is a lot for the issue that this PR is meant to solve and I think each extra optimization needs to be examined separately to make sure they (1) ...[truncated]", + "root_timestamp": "2026-07-24T03:10:40Z", + "body": "> > Thank you for working hard on this! I see there have been a lot of iterations between this PR and the previous.\r\n> \r\n> > \r\n> \r\n> > Apologies if this has already been discussed elsewhere, but I'm wondering why the solution is not to call `OtapArrowRecords::decode_transport_optimized_ids` in the various `try_from` implementations? That would be a very small change (3 lines or so) and I think solve the problem.\r\n> \r\n> > \r\n> \r\n> > In my opinion view creation should not fail unless we're seeing data corruption as there's no alternative for a caller in the failure case. This PR seems to take the same opinion, as we have updated all callers to decode before creating the view to avoid it.\r\n> \r\n> > \r\n> \r\n> > I'm wondering then why we're letting callers make the mistake of not decoding in a way that can only be found at runtime instead of proactively doing it in the implementation.\r\n> \r\n> \r\n> \r\n> Thanks for raising this. \r\n> \r\n> \r\n> \r\n> I agree that callers should not have to remember to decode first, and that this error should not normally surface in application code.\r\n> \r\n> \r\n> \r\n> The current TryFrom<&OtapArrowRecords> implementation only has immutable access, whereas decoding require ...[truncated]", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", + "no_author_action", + "no_author_action", + "author_action" + ], + "run_labels": [ "author_action", "author_action", + "no_author_action", + "no_author_action", "author_action" ] }, { - "id": "pr-review-4741233658", + "id": "pr-issue-comment-5099464449", "repo": "otel-arrow", "pull_request": 3524, "requester": "JakeDern", "pr_author": "yeomin4242", - "review_state": "COMMENTED", - "body": "Thank you for working hard on this! I see there have been a lot of iterations between this PR and the previous.\n\nApologies if this has already been discussed elsewhere, but I'm wondering why the solution is not to call `OtapArrowRecords::decode_transport_optimized_ids` in the various `try_from` implementations? That would be a very small change (3 lines or so) and I think solve the problem.\n\nIn my opinion view creation should not fail unless we're seeing data corruption as there's no alternative for a caller in the failure case. This PR seems to take the same opinion, as we have updated all callers to decode before creating the view to avoid it. \n\nI'm wondering then why we're letting callers make the mistake of not decoding in a way that can only be found at runtime instead of proactively doing it in the implementation.", + "review_state": null, + "root_timestamp": "2026-07-28T03:07:10Z", + "body": "I think we should scope this PR to the main issue, which is preventing the construction of invalid views. The `DecodedOtapLogsResources` construct that the router and validator are using look like an unrelated optimization, as those components were calling the normal `try_from` implementation before this PR. \r\n\r\nBesides the optimizations being unrelated, I'm not sure that the solutions in this PR are the best we can do. For example, having a second `OtapLogsResourcesView` construct that is a subset of the `OtapLogsView` seems like a maintenance burden and complicates the API surface area. I don't have a perfect solution here, but I'll put a couple of ideas at the bottom. \r\n\r\nAdditionally, the benefit of these optimizations is not demonstrated anywhere that I can see and there may not be sufficient impact. For example, I previously considered optimizing the views for the temporal reaggregation processor, but after profiling I did not see significant time spent there. Did you make a different discovery?\r\n\r\nIn short, I think 2000 lines of code is a lot for the issue that this PR is meant to solve and I think each extra optimization needs to be examined separately to make sure they (1) ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12030,17 +12639,18 @@ "requester": "lquerel", "pr_author": "c1ly", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-24T00:52:01Z", "body": "I believe there are few issues to fix before merging this PR. Thanks", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12051,23 +12661,24 @@ ] }, { - "id": "pr-issue-comment-5064286903", + "id": "pr-review-4759942042", "repo": "otel-arrow", "pull_request": 3557, - "requester": "drewrelmas", + "requester": "chatgpt-codex-connector", "pr_author": "youdie006", - "review_state": null, - "body": "@daviddahl can you please take a look at this PR and how it may relate to https://github.com/open-telemetry/otel-arrow/issues/3435?", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-23T00:48:05Z", + "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `c05d8b7fc2`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12078,23 +12689,24 @@ ] }, { - "id": "pr-issue-comment-5064893290", + "id": "pr-issue-comment-5064286903", "repo": "otel-arrow", "pull_request": 3557, - "requester": "daviddahl", + "requester": "drewrelmas", "pr_author": "youdie006", "review_state": null, - "body": "> @daviddahl can you please take a look at this PR and how it may relate to #3435?\r\n\r\nThis is very much complementary - we should converge if possible. A stability Enum could be added to the `component_inventory` macro - we discussed this a little bit but did not want to go all the way down to individual signal types as is done in the go collector as we are inventorying components that do not handle signals as well. Perhaps we can follow up my PR with a stability property and converge. What do you think @lquerel ?", + "root_timestamp": "2026-07-23T22:48:17Z", + "body": "@daviddahl can you please take a look at this PR and how it may relate to https://github.com/open-telemetry/otel-arrow/issues/3435?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12105,57 +12717,31 @@ ] }, { - "id": "pr-review-4759942042", + "id": "pr-issue-comment-5064893290", "repo": "otel-arrow", "pull_request": 3557, - "requester": "chatgpt-codex-connector", + "requester": "daviddahl", "pr_author": "youdie006", - "review_state": "COMMENTED", - "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `c05d8b7fc2`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", + "review_state": null, + "root_timestamp": "2026-07-24T00:32:04Z", + "body": "> @daviddahl can you please take a look at this PR and how it may relate to #3435?\r\n\r\nThis is very much complementary - we should converge if possible. A stability Enum could be added to the `component_inventory` macro - we discussed this a little bit but did not want to go all the way down to individual signal types as is done in the go collector as we are inventorying components that do not handle signals as well. Perhaps we can follow up my PR with a stability property and converge. What do you think @lquerel ?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-issue-comment-5075827036", - "repo": "otel-arrow", - "pull_request": 3571, - "requester": "lalitb", - "pr_author": "pritishnahar95", - "review_state": null, - "body": "Moved out from merge queue, as @pritishnahar95 is making some updates to align the design with the Azure identity extension.", - "role": "scored", - "stability": "flaky", - "recorded_label": null, - "adjudicated_label": null, - "run_actions": [ - "author", - "none", - "author", - "none", - "author" ], "run_labels": [ - "author_action", "no_author_action", - "author_action", "no_author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -12165,17 +12751,18 @@ "requester": "drewrelmas", "pr_author": "pritishnahar95", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T18:57:32Z", "body": "Looks good to me! Excited to see the generic implementation coming in!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12186,23 +12773,24 @@ ] }, { - "id": "pr-review-4791568931", + "id": "pr-issue-comment-5075827036", "repo": "otel-arrow", "pull_request": 3571, "requester": "lalitb", "pr_author": "pritishnahar95", - "review_state": "APPROVED", - "body": "LGTM. Thanks for putting together this detailed design and aligning it with the Azure identity extension. This will be a useful addition. \n\nI left a few comments to clarify config validation, the RFC 7523 flow, and the HTTP/TLS behavior. Approving with the expectation that these are addressed before merge.", + "review_state": null, + "root_timestamp": "2026-07-25T00:27:13Z", + "body": "Moved out from merge queue, as @pritishnahar95 is making some updates to align the design with the Azure identity extension.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12213,23 +12801,24 @@ ] }, { - "id": "pr-issue-comment-5072344416", + "id": "pr-review-4791568931", "repo": "otel-arrow", - "pull_request": 3572, - "requester": "lquerel", - "pr_author": "gnanirahulnutakki", - "review_state": null, - "body": "@gnanirahulnutakki could you sign the CLA and mark the PR ready for review.", + "pull_request": 3571, + "requester": "lalitb", + "pr_author": "pritishnahar95", + "review_state": "APPROVED", + "root_timestamp": "2026-07-27T21:15:25Z", + "body": "LGTM. Thanks for putting together this detailed design and aligning it with the Azure identity extension. This will be a useful addition. \n\nI left a few comments to clarify config validation, the RFC 7523 flow, and the HTTP/TLS behavior. Approving with the expectation that these are addressed before merge.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12246,17 +12835,18 @@ "requester": "lquerel", "pr_author": "gnanirahulnutakki", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T16:57:58Z", "body": "Thanks", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12267,30 +12857,31 @@ ] }, { - "id": "pr-issue-comment-5094184763", + "id": "pr-issue-comment-5072344416", "repo": "otel-arrow", - "pull_request": 3575, - "requester": "AaronRM", - "pr_author": "ihopenre-eng", + "pull_request": 3572, + "requester": "lquerel", + "pr_author": "gnanirahulnutakki", "review_state": null, - "body": "@lquerel Thanks for detailed clarification. I have updated the title and description of #3569 to reflect the above.", + "root_timestamp": "2026-07-24T16:58:56Z", + "body": "@gnanirahulnutakki could you sign the CLA and mark the PR ready for review.", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -12300,24 +12891,53 @@ "requester": "lquerel", "pr_author": "ihopenre-eng", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-25T06:31:03Z", "body": "Thanks for working on this, i.e. the goal of keeping `--validate-and-exit` consistent with runtime startup is definitely right.\n\nAfter reproducing #3569 against the parent commit, we found that the original analysis attributing the failure to missing type-router outputs was incorrect. We’re sorry for the confusion.\n\nThe type router recognizes three well-known named routes: `logs`, `metrics`, and `traces`. Under the existing configuration model, the outputs list is an optional declaration/allowlist; the actual ports can be established directly by connections such as router[\"logs\"], router[\"metrics\"], and router[\"traces\"]. I verified that this configuration, without an outputs list, validates, starts ready, and processes all three signal types on the parent commit.\n\nThe exact configuration from #3569 actually fails because all traffic-generator signal weights default to zero: at least one of metric_weight, trace_weight, or log_weight must be > 0\n\nRuntime calls `TrafficConfig::validate()`, but static validation only deserializes Config, so `--validate-and-exit` misses this semantic constraint.\n\nSuggested fix:\n\n- Remove the minimum-declared-output requirement from type_router.\n- Reuse ...[truncated]", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-issue-comment-5094184763", + "repo": "otel-arrow", + "pull_request": 3575, + "requester": "AaronRM", + "pr_author": "ihopenre-eng", + "review_state": null, + "root_timestamp": "2026-07-27T16:51:05Z", + "body": "@lquerel Thanks for detailed clarification. I have updated the title and description of #3569 to reflect the above.", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -12327,17 +12947,18 @@ "requester": "drewrelmas", "pr_author": "Dipanshusinghh", "review_state": "COMMENTED", + "root_timestamp": "2026-07-27T18:01:55Z", "body": "Looks good! Could you potentially add a `trafficgen` example with a few variations of this processor to validate behavior is as expected and document the results in PR description? Something like https://github.com/open-telemetry/otel-arrow/blob/main/rust/otap-dataflow/configs/trafficgen-flow-metrics-demo.yaml and #3552", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12354,24 +12975,25 @@ "requester": "drewrelmas", "pr_author": "Dipanshusinghh", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T13:42:44Z", "body": "LGTM! Left one further comment about changelog.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "author_action", "no_author_action", "no_author_action", - "author_action" + "no_author_action", + "no_author_action" ] }, { @@ -12381,24 +13003,25 @@ "requester": "cijothomas", "pr_author": "Dipanshusinghh", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T19:02:45Z", "body": "LGTM. I left a comment about further improving the changelog, not a blocker now.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "author_action", "no_author_action", "no_author_action", - "author_action" + "no_author_action", + "no_author_action" ] }, { @@ -12408,24 +13031,25 @@ "requester": "cijothomas", "pr_author": "Dipanshusinghh", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T19:03:03Z", "body": "LGTM. I left a comment about further improving the changelog, not a blocker now.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "author_action", "no_author_action", "no_author_action", - "author_action" + "no_author_action", + "no_author_action" ] }, { @@ -12435,17 +13059,18 @@ "requester": "lalitb", "pr_author": "Shaurya2k06", "review_state": null, + "root_timestamp": "2026-07-27T16:40:03Z", "body": "@Shaurya2k06 : Can we also parse hidden files as in the [example](https://raw.githubusercontent.com/lycheeverse/lychee/lychee-v0.24.2/lychee.example.toml) - `Lychee` skips hidden directories by default, so this currently misses files such as `rust/otap-dataflow/.chloggen/README.md`. That means broken relative links in those docs can still merge, contrary to the issue’s “all Markdown files” acceptance criterion.\r\n\r\n```toml\r\n# Do not skip hidden directories and files\r\nhidden = true\r\n```", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12462,17 +13087,18 @@ "requester": "Dipanshusinghh", "pr_author": "Shaurya2k06", "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T06:10:55Z", "body": "i noticed Copilot is complaining about `include_fragments = \"full\"`, but didn't `lychee` migrate this setting from a boolean to an enum (`\"none\"`, `\"anchor-only\"`, `\"full\"`) in recent versions (like v0.23+)? \n\nif so, setting it to `true` as Copilot suggests would actually cause a config parsing error now right? \n\nit looks like the author's original string value is correct here but just wanted to double-check with the team if I'm missing something", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12489,17 +13115,18 @@ "requester": "jmacd", "pr_author": "drewrelmas", "review_state": "COMMENTED", + "root_timestamp": "2026-07-28T19:32:34Z", "body": "Thanks for tackling this -- I'm fully behind the goal. A runtime error like \"No space left on device (os error 28)\" being reduced to `(1 dropped)` is exactly the kind of thing that makes internal logs useless when you need them most, and prioritizing the `error` field within the bounded record budget is the right instinct. The compact `error` / `error_kind` / `event_type` shape in the \"After\" output is a clear improvement over the old rendering.\n\nMy main concern is that a fair amount of this reimplements logic we already have, and I'd rather not carry two copies of the truncation machinery. Details below.\n\n## 1. Duplicated truncation logic\n\n`TruncatingBoundedBufFmt` + `encode_debug_string_truncating` reimplement what already exists in `crates/pdata/src/otlp/common.rs`:\n\n- `encode_string_bounded` / `encode_string_truncating` (common.rs:498-570) already handle suffix reservation, UTF-8 boundary truncation (via `truncate_utf8`), and the tri-state `Ok(false)` / `Ok(true)` / `Err(Dropped)` contract.\n- `BoundedBufFmt` (encoder.rs:238) is now a strict special case of the new adapter, so we carry two nearly identical `fmt::Write` adapters.\n- `encode_debug_attribute_truncating_to` is a copy ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12516,17 +13143,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-11-25T14:49:52Z", "body": "Nice! Thanks @thompson-tomo. I'll get back to you as soon as I can (it's a very busy EOM).", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12543,17 +13171,18 @@ "requester": "trask", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-11-26T03:19:09Z", "body": "> By switching to front matter directly it enables turning on the first line h1 check.\r\n>\r\n> Note the awk/sed command are necessary so that the document still passes the lint rules and we don't have a formatter to format it.\r\n\r\ncan these be done in a follow-up PR? if so, please revert those changes to keep this large mechanical PR easy to review", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12564,23 +13193,24 @@ ] }, { - "id": "pr-issue-comment-3582994604", + "id": "pr-review-3512552586", "repo": "semantic-conventions", "pull_request": 2971, "requester": "chalin", "pr_author": "thompson-tomo", - "review_state": null, - "body": "> The one thing which i am not sure on is if the aliases in [resource-and-entities.md](https://github.com/open-telemetry/semantic-conventions/pull/2971/files#diff-45c6c3aee5d1ce4f912148cf9efc0f39984b2c4c8f67f806bd99d6ce263dac21) are still valid. If not we could switch to a redirect\r\n\r\nYes the alias is valid, but I'd rather keep the inline array syntax, esp. in these cases that have a single entry.", + "review_state": "COMMENTED", + "root_timestamp": "2025-11-26T19:51:28Z", + "body": "A first few questions and comments:\r\n\r\n- Spec and semconv folks expressedly asked me to include the comment \"Hugo front matter used to generate the website version of this page\" so that all contributors know why the front matter is there (and hopefully realize that it's important to keep it up to date). Maybe this preference has changed. I'll let @open-telemetry/specs-maintainers @open-telemetry/specs-semconv-maintainers comment about this. I'm ok either way.\r\n- Why not keep the (inline) array syntax for aliases?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12590,6 +13220,34 @@ "author_action" ] }, + { + "id": "pr-issue-comment-3582994604", + "repo": "semantic-conventions", + "pull_request": 2971, + "requester": "chalin", + "pr_author": "thompson-tomo", + "review_state": null, + "root_timestamp": "2025-11-26T19:52:11Z", + "body": "> The one thing which i am not sure on is if the aliases in [resource-and-entities.md](https://github.com/open-telemetry/semantic-conventions/pull/2971/files#diff-45c6c3aee5d1ce4f912148cf9efc0f39984b2c4c8f67f806bd99d6ce263dac21) are still valid. If not we could switch to a redirect\r\n\r\nYes the alias is valid, but I'd rather keep the inline array syntax, esp. in these cases that have a single entry.", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "author_action", + "author_action", + "author_action", + "no_author_action" + ], + "run_labels": [ + "no_author_action", + "author_action", + "author_action", + "author_action", + "no_author_action" + ] + }, { "id": "pr-issue-comment-3583001541", "repo": "semantic-conventions", @@ -12597,17 +13255,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-11-26T19:54:44Z", "body": "FYI, I haven't had the time to look into this more, but in support of #1821 and https://github.com/open-telemetry/opentelemetry.io/issues/6101. We probably will need to have a `title` field in the front matter too.\r\n\r\nI'm wrapping up and will be OOO so I won't be able to get back to this until the new year (FYI).", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12624,17 +13283,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-11-27T00:11:26Z", "body": "> Build issue due to current toc generator having known issues with front matter syntax & isn't mantained. Will need to be addressed by switching to https://www.npmjs.com/package/doctoc\r\n\r\nOMG, the last update was 8 years ago in NPM. doctoc seems like an interesting choice; https://npm-compare.com/doctoc,markdown-toc\r\n\r\nMaybe it would be worth switching toc tools before working further on this PR?\r\n\r\n/cc @vitorvasc", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12651,22 +13311,23 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-11-27T13:03:55Z", "body": "Hmm. Ok, maybe another tool then.\r\n(Creating a markdownlint rule to handle tocs might be a fun project ;))", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", "no_author_action", + "author_action", "no_author_action", "no_author_action" ] @@ -12678,24 +13339,25 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-11-28T20:10:22Z", "body": "Btw, if you still need to massage the files, rathr than awk & sed, I'd suggest using Perl because it is more portable across OSs and container environments in my experience (esp. if you avoid Perl modules that don't ship with Perl).", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "author_action", + "author_action", + "author_action", + "no_author_action" ], "run_labels": [ + "no_author_action", "author_action", "author_action", "author_action", - "author_action", - "author_action" + "no_author_action" ] }, { @@ -12705,17 +13367,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-01-27T18:34:24Z", "body": "> Note I am still working towards a release of doctoc which will eliminate the grep etc but that will be seperate PR.\r\n\r\nGreat that you've been able to get some doctoc changes merged. 🙌🏻 \r\n\r\nWhile I'm eager to make progress here, our current setup works. I'd rather not move forward until we have a full solution that includes:\r\n\r\n- `title` field in the front matter. Both the in-page h1 and title text should match (could be enforced in this repo)\r\n- I think that if we're going to change the toc tool, that should be done first\r\n- IMHO, we should reach a point where the only change introduced in the .md files by this PR would be to replace the HTML comment delimiters (used to wrap the front matter) by YAML `---` section delimiters.\r\n\r\nWDYT?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12732,17 +13395,46 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-02-13T19:09:08Z", "body": "> There doesn't appear to be any usage of `title` front matter\r\n\r\n- The OTel.io layouts expect a `title`, so it needs to be there (at least for now).\r\n\r\n---\r\n\r\n- Thinking about the Hugo comment: at this point I think that there's enough maintainer / community experience that we could probably drop it.\r\n\r\n- I'd vote to switch tools first.\r\n\r\n---\r\n\r\n> I assume you don't mean to create a seperate PR to split the hugo comment to be on a separate line if you want to keep the hugo comment?\r\n\r\nYeah, assuming the Hugo comment goes it mostly looks like what is done in this PR (execpt for the array format changes that should be undone):\r\n\r\n\"image\"", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-3841040831", + "repo": "semantic-conventions", + "pull_request": 2971, + "requester": "chalin", + "pr_author": "thompson-tomo", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-02-23T13:22:22Z", + "body": "> @chalin i have now gone and added title front matter to all the pages, \n\nGreat!\n\nLet's follow convention and ensure that the `title` is the first front-matter field.\n\n> there is a custom textlint rule which ensures that they match if not report an error, \n\nNice, though I'd rather not introduce textlint into the toolchain if we can avoid it. I'd prefer that we use a custom Markdownlint rule instead (I've been writing custom mdl2 rules lately, so I can look into it if that can help).\n\nThat being said, if we don't want to delay the front-matter conversion of this PR, we can move the tooling bits to a followup PR. \n\n> @chalin this repo can now switch to doctoc as update is now available. PR to switch is #3463 ...\n\nWell done! I left a review comment with suggested changes. Looking forward to seeing that merged once suggestions are addressed.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12759,17 +13451,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-02-23T14:36:52Z", "body": "> Let's do tooling seperate, would you rather I remove textlint from this PR or keep it and then remove the custom rule later?\r\n\r\nFactor it out into another PR (and remove it from this one).", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12786,17 +13479,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-02-23T16:04:33Z", "body": "To followup on the textlint rule: I'm not against it, esp. if textlint does become a part of the toolchain (as it has in the main spec repo), but we can discuss that separately now that there will be another PR for the tool.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -12813,17 +13507,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-04-24T18:43:16Z", "body": "@thompson-tomo - let's get #3463 in first, I just submitted a review.\r\n\r\nBtw, I was OOO in March. Been juggling other priorities since then, but this is still on my radar. Note that the follow will be supportive of the work done in this PR:\r\n\r\n- https://github.com/open-telemetry/opentelemetry-specification/issues/5049", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12840,44 +13535,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-03T17:01:26Z", "body": "@thompson-tomo - can you ensure that this is up to date, and I'll start final tests on the otel.io side to ensure that this can land smoothly.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-issue-comment-4878507963", - "repo": "semantic-conventions", - "pull_request": 2971, - "requester": "chalin", - "pr_author": "thompson-tomo", - "review_state": null, - "body": "> I have just updated the branch and completed an audit so it is up to date.\r\n\r\nHow did you \"complete the audit\"? Do you have a script? Is it a part of this repo already?\r\n\r\n> So currently there is nothing in place to keep them in sync ...\r\n\r\nI'm ok landing this earlier and brining in the sync check later.\r\n\r\n> ... I did previously have a custom textlint rule in-place.\r\n\r\n~Right, that rings a bell. Where is that work? Is textlint already a part of this repo's toolchain? I vaguely recall commenting on this (in this repo or the main spec repo?); possibly even mentioning that I'd more likely favor use of markdownlint instead.~ (Nm, found the context) In any case, we can land the changes first so that this PR isn't delayed.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -12888,23 +13557,24 @@ ] }, { - "id": "pr-review-3512552586", + "id": "pr-review-4627288181", "repo": "semantic-conventions", "pull_request": 2971, "requester": "chalin", "pr_author": "thompson-tomo", "review_state": "COMMENTED", - "body": "A first few questions and comments:\r\n\r\n- Spec and semconv folks expressedly asked me to include the comment \"Hugo front matter used to generate the website version of this page\" so that all contributors know why the front matter is there (and hopefully realize that it's important to keep it up to date). Maybe this preference has changed. I'll let @open-telemetry/specs-maintainers @open-telemetry/specs-semconv-maintainers comment about this. I'm ok either way.\r\n- Why not keep the (inline) array syntax for aliases?", + "root_timestamp": "2026-07-03T17:28:25Z", + "body": "@thompson-tomo - FYI, I'll be making some progress on this this month. See inline comments for a tweak and question.\n\nBtw, what's in place to ensure that the Hugo fm title and page title match. I thought that we had a checker in place, but I'm not seeing that in the scope of this PR.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12915,23 +13585,24 @@ ] }, { - "id": "pr-review-3841040831", + "id": "pr-issue-comment-4878507963", "repo": "semantic-conventions", "pull_request": 2971, "requester": "chalin", "pr_author": "thompson-tomo", - "review_state": "CHANGES_REQUESTED", - "body": "> @chalin i have now gone and added title front matter to all the pages, \n\nGreat!\n\nLet's follow convention and ensure that the `title` is the first front-matter field.\n\n> there is a custom textlint rule which ensures that they match if not report an error, \n\nNice, though I'd rather not introduce textlint into the toolchain if we can avoid it. I'd prefer that we use a custom Markdownlint rule instead (I've been writing custom mdl2 rules lately, so I can look into it if that can help).\n\nThat being said, if we don't want to delay the front-matter conversion of this PR, we can move the tooling bits to a followup PR. \n\n> @chalin this repo can now switch to doctoc as update is now available. PR to switch is #3463 ...\n\nWell done! I left a review comment with suggested changes. Looking forward to seeing that merged once suggestions are addressed.", + "review_state": null, + "root_timestamp": "2026-07-03T18:05:05Z", + "body": "> I have just updated the branch and completed an audit so it is up to date.\r\n\r\nHow did you \"complete the audit\"? Do you have a script? Is it a part of this repo already?\r\n\r\n> So currently there is nothing in place to keep them in sync ...\r\n\r\nI'm ok landing this earlier and brining in the sync check later.\r\n\r\n> ... I did previously have a custom textlint rule in-place.\r\n\r\n~Right, that rings a bell. Where is that work? Is textlint already a part of this repo's toolchain? I vaguely recall commenting on this (in this repo or the main spec repo?); possibly even mentioning that I'd more likely favor use of markdownlint instead.~ (Nm, found the context) In any case, we can land the changes first so that this PR isn't delayed.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12942,23 +13613,24 @@ ] }, { - "id": "pr-review-4627288181", + "id": "pr-review-4633618775", "repo": "semantic-conventions", "pull_request": 2971, - "requester": "chalin", + "requester": "joaopgrassi", "pr_author": "thompson-tomo", - "review_state": "COMMENTED", - "body": "@thompson-tomo - FYI, I'll be making some progress on this this month. See inline comments for a tweak and question.\n\nBtw, what's in place to ensure that the Hugo fm title and page title match. I thought that we had a checker in place, but I'm not seeing that in the scope of this PR.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-06T07:14:09Z", + "body": "Before even reviewing this, I'd like us to have a mechanism to:\n\n1. Check that each page has the frontmatter\n2. That it matches the header\n\nWithout it this will become stale, so I think it needs to be done together and not as a follow up.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12969,23 +13641,24 @@ ] }, { - "id": "pr-review-4633618775", + "id": "pr-issue-comment-4028246294", "repo": "semantic-conventions", - "pull_request": 2971, - "requester": "joaopgrassi", - "pr_author": "thompson-tomo", - "review_state": "CHANGES_REQUESTED", - "body": "Before even reviewing this, I'd like us to have a mechanism to:\n\n1. Check that each page has the frontmatter\n2. That it matches the header\n\nWithout it this will become stale, so I think it needs to be done together and not as a follow up.", + "pull_request": 3515, + "requester": "trask", + "pr_author": "PascalSenn", + "review_state": null, + "root_timestamp": "2026-03-10T02:51:43Z", + "body": "re-opening for discussion!\r\n\r\n@PascalSenn also check out https://github.com/open-telemetry/opentelemetry-specification/pull/4906\r\n\r\nthere has been quite a bit of progress since we discussed last year about the option of hosting semantic conventions outside of this repository. I think the work is pretty bleeding edge still but may be ready for external usage soon. In the meantime, let's review and discuss the GraphQL semantic conventions here.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -12996,23 +13669,24 @@ ] }, { - "id": "pr-issue-comment-4028246294", + "id": "pr-review-4216502112", "repo": "semantic-conventions", "pull_request": 3515, - "requester": "trask", + "requester": "thompson-tomo", "pr_author": "PascalSenn", - "review_state": null, - "body": "re-opening for discussion!\r\n\r\n@PascalSenn also check out https://github.com/open-telemetry/opentelemetry-specification/pull/4906\r\n\r\nthere has been quite a bit of progress since we discussed last year about the option of hosting semantic conventions outside of this repository. I think the work is pretty bleeding edge still but may be ready for external usage soon. In the meantime, let's review and discuss the GraphQL semantic conventions here.", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-03T16:15:58Z", + "body": "Just a couple of small doc tweaks which will need a fresh markdown generated.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13029,17 +13703,18 @@ "requester": "nlamirault", "pr_author": "PascalSenn", "review_state": null, + "root_timestamp": "2026-06-04T15:27:05Z", "body": "Any news on this feature ? Tks.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13056,21 +13731,22 @@ "requester": "thompson-tomo", "pr_author": "PascalSenn", "review_state": null, + "root_timestamp": "2026-06-22T12:29:43Z", "body": "@PascalSenn unfortunately i dont have permissions to. Ping @open-telemetry/specs-semconv-approvers @open-telemetry/specs-semconv-maintainers", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "author_action", + "no_author_action", "no_author_action", "no_author_action", "no_author_action" @@ -13083,50 +13759,25 @@ "requester": "kamphaus", "pr_author": "PascalSenn", "review_state": null, + "root_timestamp": "2026-06-22T12:36:56Z", "body": "Here you go @PascalSenn", - "role": "context", - "stability": null, - "recorded_label": null, + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - null, - "none", - "none", - "none", - "none" - ], - "run_labels": [ + "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4216502112", - "repo": "semantic-conventions", - "pull_request": 3515, - "requester": "thompson-tomo", - "pr_author": "PascalSenn", - "review_state": "COMMENTED", - "body": "Just a couple of small doc tweaks which will need a fresh markdown generated.", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -13136,17 +13787,18 @@ "requester": "hegerchr", "pr_author": "SylvainJuge", "review_state": null, + "root_timestamp": "2026-07-13T12:35:05Z", "body": "Hi maintainers (@AlexanderWert , @arminru , @kamphaus , @joaopgrassi , @jsuereth , @lmolkova , @trask ), is there anything that's blocking progress on this? Would be really great to get the sem conv merged to unblock implementations.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -13163,22 +13815,24 @@ "requester": "lmolkova", "pr_author": "SylvainJuge", "review_state": "COMMENTED", + "root_timestamp": "2026-07-17T18:29:19Z", "body": "A few minor suggestions, looks good otherwise!", - "role": "context", - "stability": null, + "role": "scored", + "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - null, - "author", - "author" + "no_author_action", + "no_author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ - "author_action", + "no_author_action", "no_author_action", "author_action", + "no_author_action", "author_action" ] }, @@ -13189,17 +13843,18 @@ "requester": "chalin", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-02T11:21:41Z", "body": "Not stale.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -13216,17 +13871,18 @@ "requester": "joaopgrassi", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-06T07:08:03Z", "body": "@chalin I guess \"code owner\" here would be you. Can you approve to make sure from the OTel website things look ok?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -13236,6 +13892,34 @@ "no_author_action" ] }, + { + "id": "pr-review-4262370828", + "repo": "semantic-conventions", + "pull_request": 3686, + "requester": "florianl", + "pr_author": "thompson-tomo", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-05-11T09:44:27Z", + "body": "From a Profiling perspective this is a hard breaking change that will cause issues around symbolization.\nInstead of replacing `process.executable.path` with `process.entrypoint`, `process.entrypoint` should be a complementary attribute and independent from `process.executable.path`.\n\nE.g. in a process that uses pytorch to do something, there will be multiple `process.executable.path` from a Profiling perspective. One for `/usr/bin/python` (or any other path to a python runtime executable), one for something like `libtorch` and maybe something device/GPU specific.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-4420373673", "repo": "semantic-conventions", @@ -13243,17 +13927,18 @@ "requester": "florianl", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-05-11T11:46:05Z", "body": "I view the `process.executable.*` namespace, which encompasses `build_id.gnu`, `build_id.go`, `build_id.htlhash`, `name`, and `path`, as a cohesive unit. Collectively, these attributes serve to uniquely identify an element.\r\n\r\nRedirecting the `process.executable.build_id.*` sub-namespace to `process.entrypoint` for executable identification does not seem appropriate. Consequently, I consider `process.entrypoint` to be a complementary addition rather than a replacement for `process.executable.path`.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13270,24 +13955,25 @@ "requester": "florianl", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-05-11T13:52:10Z", "body": ">> Redirecting the process.executable.build_id.* sub-namespace to process.entrypoint for executable identification does not seem appropriate.\r\n>>\r\n> Isn't the build_id.htlhash sufficient to uniquely identify the executable? \r\n\r\nYes - `process.executable.build_id.htlhash` can uniquely identify a executable. But as hashes are hard for human to comprehent and trigger actions, more descriptive attributes (like `process.executable.path`) are needed.", "role": "scored", "stability": "stable", - "recorded_label": "no_author_action", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -13297,17 +13983,18 @@ "requester": "braydonk", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-06-01T13:15:59Z", "body": "My concern is just that this seems really hard to instrument, and really hard to implement as a general `process` namespace attribute. The instructions for how to parse the cmdline of the process to get the nominal \"entrypoint\" (like the example instructions for Python in the description) are probably going to need to exist for any runtime. Wouldn't it be better to introduce entities for the different runtimes that have their own proper instructions for determining entrypoint where that is actually useful? A majority of usecases in the general process world won't really need anything more than uniquely identifying the current executable of the process.\r\n\r\n> Compliment it with either process.launch_path or process.run_path to be capturing what is being launched/run by the entrypoint.\r\n\r\nTo my knowledge, there isn't a way to know this at any given time (short of parsing cmdline but often that doesn't actually contain the full path). You could only instrument it if you were the process yourself, guaranteeing you know when you start and reporting your own entrypoint at that point in time. Any other usecase couldn't guarantee that what they are reading is definitely the path to the exec ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13324,17 +14011,18 @@ "requester": "braydonk", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-06-23T17:15:26Z", "body": "> my updated proposal is to simply to rename the attribute and move the new attribute to the process entity. The note is made more explicit see suggestion https://github.com/open-telemetry/semantic-conventions/pull/3686#discussion_r3219625536\r\n\r\nI don't think we need to rename `process.executable.path` to add `process.entrypoint`, I think they're distinct. The proposal in the linked comment seems to describe `process.entrypoint` as being the same as `/proc/[pid]/exe`; to my understanding, that is explicitly not the goal of the attribute. Why can't we leave `process.executable.path` to mean that and `process.entrypoint` as a new attribute?\r\n\r\n> move the new attribute to the process entity\r\n\r\nThis attribute likely does make the most sense on the `process` entity, but I think we should keep `process.executable.path` in the `process.executable` entity. This attribute is different and not a sufficient replacement.\r\n\r\n> Yes this would be an opt-in self reported descriptive attribute and it could be discussed further in the future.\r\n\r\nI guess I can get behind it as long as it's clear that default instrumentation is unlikely to report it. The attribute can be designed for situations where ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13351,17 +14039,18 @@ "requester": "braydonk", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-23T15:09:00Z", "body": "> This PR seeks to rename Process.executable.path to process.launch_path, there is no change in how it is sourced.\r\n\r\nThat's actually even more incorrect. The expected instrumentation for the process entity could never tell at any given time that the detected executable for the process is the same as the path that it was launched with. It could be changed at any time. So the name is very misleading, and as written I don't think it should be on the entity.\r\n\r\n> This PR moves the attribute from the process.executable entity to the process entity. This is so process.executable supports the scenario of multiple identical executables on a system. If we didn' we would have un-necessary churn of the value of the descriptive attribute & could lead to wrong info. There would be no way to distinguish between the different copies on the same system.\r\n\r\nBut you still can't do that. Removing `process.executable.path` from the `process.executable` entity doesn't make it so you are able to do that. You have a very similar problem as before. You get rid of the path as a churn, but two different copies of the executable would still look like one to the backend since the only identifying attributes ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13378,17 +14067,18 @@ "requester": "braydonk", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-23T15:52:49Z", "body": "> If you are not a supporter of process.launch_path what about process.run_path/process.running_path that way we can say it is path to what is running in the process?\r\n\r\nMy favourite option is to keep it named `process.executable.path`. That's a literal description of what it is that matches common nomenclature. \r\n\r\nP.S. I think `process.executable.name` and `process.executable.path` being attributes on `process.executable` is actually kind of weird; `process.executable.path` is a reasonable name here because when describing this property of a process, yes it is the current path to the process's executable. But a `process.executable` entity is nominally just representing a file, so there is no reason for attributes like `process.executable.path` and `process.executable.name` to exist separate from simply `file.path` and `file.name`.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13405,24 +14095,25 @@ "requester": "braydonk", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-23T16:54:32Z", "body": "> Then we have 2 usages/meanings for process.executable\r\n\r\nIt's not really different. It is the path to the process's executable. It's about an executable. That's not ambiguous to me at all.\r\n\r\n> what about process.executing_path or process.execution_path?\r\n\r\nNot a fan of those; non-standard nomenclature, and could be very confusing. What we're trying to describe is \"the path to the executable run by the process\", so calling that \"execution path\" isn't exactly stating that clearly.\r\n\r\n> The problem is profiling needs to be able to get a name for the executable identified by the id.\r\n\r\nYeah the `process.executable` entity can have a name and path, I think that's fine. My problem with the `process.executable` entity is that most of its properties are just normal properties of a file. Having special `process.executable` attributes for `path` and `name` don't make sense on that entity when you could communicate identical information with `file.path` and `file.name`. `process.executable.path` is a name that made sense in context of the `process` entity itself, because a \"process\" has an \"executable\" that it's running and you can retrieve the \"path\" to it. But all of that relevance was e ...[truncated]", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", "author_action", - "no_author_action" + "author_action" ] }, { @@ -13432,44 +14123,18 @@ "requester": "braydonk", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2026-07-27T16:39:18Z", "body": "> The ambiguity is, is it describing a file on the file system or is it an executable which can be deployed to 1 or more locations.\r\n\r\nThat doesn't make sense to me. An executable is always a file on the filesystem.\r\n\r\n> My preferred was *.executing_path as That would complement *.working_directory.\r\n\r\nI assume you just mean the pattern of naming is the complement, but just in case you mean otherwise; the path to the executable and the working directory of the process have absolutely no conceptual relationship.\r\n\r\n> That sounds like an entity relationship\r\n\r\n(Assuming Linux to simplify the technical explanation of this)\r\n\r\nYou could call it that. The process has an executable, which is a file on disk with an inode that at some point throughout the process's lifetime had a named hard link on the filesystem to the inode. You can identify that file by its inode. But at any given point, that file could be \"moved\" in the filesystem changing the name of the link, or be unlinked and thus no longer be accessible via the filesystem (but the inode will be present on disk until any process using it has concluded). It is conceptually a `has-a` relationship. But that relationship is to a file o ...[truncated]", "role": "scored", - "stability": "flaky", - "recorded_label": null, - "adjudicated_label": null, - "run_actions": [ - "author", - "none", - "none", - "author", - "none" - ], - "run_labels": [ - "author_action", - "no_author_action", - "no_author_action", - "author_action", - "no_author_action" - ] - }, - { - "id": "pr-review-4262370828", - "repo": "semantic-conventions", - "pull_request": 3686, - "requester": "florianl", - "pr_author": "thompson-tomo", - "review_state": "CHANGES_REQUESTED", - "body": "From a Profiling perspective this is a hard breaking change that will cause issues around symbolization.\nInstead of replacing `process.executable.path` with `process.entrypoint`, `process.entrypoint` should be a complementary attribute and independent from `process.executable.path`.\n\nE.g. in a process that uses pytorch to do something, there will be multiple `process.executable.path` from a Profiling perspective. One for `/usr/bin/python` (or any other path to a python runtime executable), one for something like `libtorch` and maybe something device/GPU specific.", - "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13486,17 +14151,18 @@ "requester": "Dipanshusinghh", "pr_author": "cijothomas", "review_state": "COMMENTED", + "root_timestamp": "2026-06-24T09:19:49Z", "body": "Two things worth fixing:\r\n\r\n1. [BLOCKER] `TonicLogsClient` maps all errors to `failed` — \r\n`timed_out` case is missing. Match on `OTelSdkError::Timeout(_)` \r\nlike `BatchLogProcessor` does, otherwise the POC doesn't fully \r\nvalidate the spec.\r\n\r\n2. [NIT] `cfg_attr` on `component_name` will need manual update \r\nwhen a third feature uses it. Allocating it always is simpler.\r\n\r\nRest looks good for a POC.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13513,17 +14179,18 @@ "requester": "lmolkova", "pr_author": "cijothomas", "review_state": "COMMENTED", + "root_timestamp": "2026-06-25T17:22:35Z", "body": "Look great! the only important comment I have is adding `error.type` instead of result attribute.\r\n\r\n[UPDATE] Added another comment on modeling it as a span", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13540,17 +14207,18 @@ "requester": "thompson-tomo", "pr_author": "Dipanshusinghh", "review_state": "COMMENTED", + "root_timestamp": "2026-07-18T14:35:35Z", "body": "On a first pass it looked good however on thinking about usages etc, i get worried about the broadness of the definition and the explosion of spans that would be created. Which is why a prototype & mapping for other tools is important.\n\nMy suggestion is clearly narrow the scope of the span to cli operations which interact with a remote and complement it with 1 or more events to capture the cli calls.\n\nThese events should be in a seperate pr and i would suggest for the prototype you could use the github reciever in the collector to generate the events based on the scraped logs.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13567,44 +14235,46 @@ "requester": "kamphaus", "pr_author": "emmayusufu", "review_state": null, + "root_timestamp": "2026-07-20T21:10:00Z", "body": "> bringing it to the system semconv working group\r\n\r\nYes, that's a good way forward.\r\nAlso you might want to periodically merge in the latest changes from main.", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-issue-comment-4914283588", + "id": "pr-review-4648046102", "repo": "semantic-conventions", "pull_request": 3860, - "requester": "thompson-tomo", + "requester": "chatgpt-codex-connector", "pr_author": "kathiehuang", - "review_state": null, - "body": "> since replicas scale under a specific revision, did you think about adding azure.container_app.revision (mapped to CONTAINER_APP_REVISION_NAME)? might be useful for tracking version of the app later on\n\nThis would reside on a seperate entity which is identified using this attribute and the name, just like done with the service entities.", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-07T18:53:10Z", + "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `eaf4a67aca`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -13615,23 +14285,24 @@ ] }, { - "id": "pr-issue-comment-4916613873", + "id": "pr-review-4651858067", "repo": "semantic-conventions", "pull_request": 3860, "requester": "Dipanshusinghh", "pr_author": "kathiehuang", - "review_state": null, - "body": "looks great just a quick heads up yamllint check is failing because changelog note line is >200 chars once u wrap/shorten it pr looks goods", + "review_state": "COMMENTED", + "root_timestamp": "2026-07-08T07:27:33Z", + "body": "nice changes! just a couple of minor things:\r\n\r\n- in model/azure/registry.yaml, should we add stability: development to the new registry.azure.container_apps group too? just to be consistent with other groups like cosmosdb.\r\n\r\n - since replicas scale under a specific revision, did you think about adding azure.container_app.revision (mapped to CONTAINER_APP_REVISION_NAME)? might be useful for tracking version of the app later on", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13642,23 +14313,24 @@ ] }, { - "id": "pr-review-4648046102", + "id": "pr-issue-comment-4914283588", "repo": "semantic-conventions", "pull_request": 3860, - "requester": "chatgpt-codex-connector", + "requester": "thompson-tomo", "pr_author": "kathiehuang", - "review_state": "COMMENTED", - "body": "### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `eaf4a67aca`\n \n\n
ℹ️ About Codex in GitHub\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n
", + "review_state": null, + "root_timestamp": "2026-07-08T11:25:35Z", + "body": "> since replicas scale under a specific revision, did you think about adding azure.container_app.revision (mapped to CONTAINER_APP_REVISION_NAME)? might be useful for tracking version of the app later on\n\nThis would reside on a seperate entity which is identified using this attribute and the name, just like done with the service entities.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -13669,23 +14341,24 @@ ] }, { - "id": "pr-review-4651858067", + "id": "pr-issue-comment-4916613873", "repo": "semantic-conventions", "pull_request": 3860, "requester": "Dipanshusinghh", "pr_author": "kathiehuang", - "review_state": "COMMENTED", - "body": "nice changes! just a couple of minor things:\r\n\r\n- in model/azure/registry.yaml, should we add stability: development to the new registry.azure.container_apps group too? just to be consistent with other groups like cosmosdb.\r\n\r\n - since replicas scale under a specific revision, did you think about adding azure.container_app.revision (mapped to CONTAINER_APP_REVISION_NAME)? might be useful for tracking version of the app later on", + "review_state": null, + "root_timestamp": "2026-07-08T15:48:19Z", + "body": "looks great just a quick heads up yamllint check is failing because changelog note line is >200 chars once u wrap/shorten it pr looks goods", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13702,17 +14375,18 @@ "requester": "lmolkova", "pr_author": "sudarshan12s", "review_state": "COMMENTED", + "root_timestamp": "2026-07-17T18:45:01Z", "body": "That's awesome!\n\nI'd like to check if we can deprecate or remove V$SESSION section", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13729,17 +14403,18 @@ "requester": "lmolkova", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-23T18:32:37Z", "body": "```\r\nRun make textlint\r\nsemantic-conventions@ /home/runner/work/semantic-conventions/semantic-conventions\r\n├─┬ textlint-filter-rule-allowlist@4.0.0\r\n│ └── textlint@15.7.1 deduped\r\n├─┬ textlint-rule-period-in-header@0.1.2\r\n│ └── textlint@15.7.1 deduped\r\n└── textlint@15.7.1\r\n\r\n\r\n/home/runner/work/semantic-conventions/semantic-conventions/.chloggen/web_vital-attributes.yaml\r\n 13:69 ✓ error Incorrect term: “id”, use “ID” instead terminology\r\n\r\n✖ 1 problem (1 error, 0 warnings, 0 infos)\r\n✓ 1 fixable problem.\r\nTry to run: $ textlint --fix [file]\r\nmake: *** [Makefile:115: textlint] Error 1\r\n```", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13756,17 +14431,46 @@ "requester": "lmolkova", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-23T18:33:57Z", "body": "@copilot now go fix the violation and update title to say that we fixed it", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4769333480", + "repo": "semantic-conventions", + "pull_request": 3928, + "requester": "thompson-tomo", + "pr_author": "copilot-swe-agent", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-24T01:07:22Z", + "body": "This actually removes functionality. Currently the filepath is used to report it as an annotation\n![image](https://github.com/user-attachments/assets/3bedefc4-12ec-484c-b198-8778bbe08a56)\n\nThis enables a reviewer to see directly on a changed file the issues hence is easier then scrolling through logs.\n\n![image](https://github.com/user-attachments/assets/433c6777-93b0-460b-9fb9-345cb4f2693c)\n\nAlso the fix is not correct as id represents a field name which is lowercased and not upper, to fix either chang config aka #3929 to ignore the directory or #3930 which uses backticks to indicate it is a field/attribute name.", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13783,17 +14487,18 @@ "requester": "lmolkova", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-24T02:00:13Z", "body": "Annotation is not as helpful as ci log, much harder to see regardless is you're a human or an agent. It's nice to have, but not at a cost of not having filename in the plain text.\r\n\r\nEspecially problematic when error is on the file that's not in the PR - current problem.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13810,24 +14515,25 @@ "requester": "thompson-tomo", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-24T02:15:01Z", "body": "Current problem is an edge case which only occurs during merge process and files changing before merge.\n\nI am not following how it is harder on humans for issues going forward as for everyone reviewing the files via the changes tab can see issues on the file inline that way they have max context. They can also see them at the top of the check which is where they go to get their logs.\n\nIt should be easier for agents as now the check itself provides a list of errors & their location.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", - "no_author_action", "author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -13837,24 +14543,24 @@ "requester": "lmolkova", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-24T02:21:03Z", "body": "Edge case maybe, it's not the last time it happens - textlint will get new rules and they'll fail in random places. \r\n\r\nThere literally no information when it does on where the problem is\r\n\r\n\"Screenshot_20260723-190553\"\r\n \r\nI'm going to repeat that path on log is a must, github comment is nice to have. Going through all github comments is much harder than looking into ci logs.", - "role": "scored", - "stability": "flaky", + "role": "context", + "stability": null, "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "author", - "author" + "no_author_action", + "author_action", + null, + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "author_action", "author_action", - "author_action", - "author_action" + "no_author_action" ] }, { @@ -13864,24 +14570,25 @@ "requester": "thompson-tomo", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-24T02:29:17Z", "body": "It's right there in the annotations section at the top of the screen. Annotations are similar to comments but are different.\n\nAlso all rules are implemented as npm packages so we need to explicitly enable the additional npm package we have added to our project for it to result in a difference in behaviour.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "none", - "none" + "author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ "author_action", "no_author_action", "no_author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -13891,17 +14598,18 @@ "requester": "lmolkova", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-24T16:56:28Z", "body": "It's wonderful to see annotations.\r\nIt's not wonderful that they show up collapsed - that's probably why I never look at them. Thanks for educating me they show up there.\r\nIt's not acceptable that they turn off file locations in the CI logs. \r\n\r\n\r\n------\r\n\r\nyamllint for example, does it well: https://github.com/open-telemetry/semantic-conventions/actions/runs/29971521674/job/89094348620?pr=3919\r\n\r\n\"image\"\r\n\r\nannotations and CI logs are not mutually exclusive. If textlint does it right, I'll be happy to enable github format.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13918,47 +14626,49 @@ "requester": "thompson-tomo", "pr_author": "copilot-swe-agent", "review_state": null, + "root_timestamp": "2026-07-26T13:23:00Z", "body": "No worries, key thing is annotations appear in 3 spots: workflow, job & file if the file location is in the diff view.\n\nIt is always hard as what is right for 1 person might not be for another especially in terms of log message content in a structured log.\n\nTbh i had expected when viewing the raw logs to see the details used to build the annotation but it is even removed from there. As such i have https://github.com/textlint/textlint/pull/2094 to log an additional line prior to the annotation with the location details. This avoids duplicated info appearing in the annotation while still providing location info in raw logs.\n\nGiven we have the annotations, all rules are dedicated npm packages hence we won't run into updates detecting new issues & i have a pr to log an additional line with the location. Could we leave it as is?", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", - "no_author_action", + "author_action", "author_action", "author_action" ] }, { - "id": "pr-review-4769333480", - "repo": "semantic-conventions", - "pull_request": 3928, - "requester": "thompson-tomo", - "pr_author": "copilot-swe-agent", - "review_state": "CHANGES_REQUESTED", - "body": "This actually removes functionality. Currently the filepath is used to report it as an annotation\n![image](https://github.com/user-attachments/assets/3bedefc4-12ec-484c-b198-8778bbe08a56)\n\nThis enables a reviewer to see directly on a changed file the issues hence is easier then scrolling through logs.\n\n![image](https://github.com/user-attachments/assets/433c6777-93b0-460b-9fb9-345cb4f2693c)\n\nAlso the fix is not correct as id represents a field name which is lowercased and not upper, to fix either chang config aka #3929 to ignore the directory or #3930 which uses backticks to indicate it is a field/attribute name.", + "id": "pr-issue-comment-4403857362", + "repo": "semantic-conventions-genai", + "pull_request": 98, + "requester": "Nik-Reddy", + "pr_author": "Krishnachaitanyakc", + "review_state": null, + "root_timestamp": "2026-05-08T06:05:11Z", + "body": "@Krishnachaitanyakc This is well thought out, the prior art table and design decisions section are really helpful. One thing I noticed, the scenarios only emit trigger=\"direct\" but never trigger=\"agent\". \r\n\r\nI get that the current scenarios don't naturally exercise delegation, but would it be worth adding a minimal multi-agent scenario (even a simple A delegates to B mock) to validate the agent value e2e? Otherwise LGTM on the model and registry changes.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "author_action", + "no_author_action", "author_action", "author_action", "author_action", @@ -13966,23 +14676,24 @@ ] }, { - "id": "pr-issue-comment-4403857362", + "id": "pr-review-4289703879", "repo": "semantic-conventions-genai", "pull_request": 98, - "requester": "Nik-Reddy", + "requester": "MikeGoldsmith", "pr_author": "Krishnachaitanyakc", - "review_state": null, - "body": "@Krishnachaitanyakc This is well thought out, the prior art table and design decisions section are really helpful. One thing I noticed, the scenarios only emit trigger=\"direct\" but never trigger=\"agent\". \r\n\r\nI get that the current scenarios don't naturally exercise delegation, but would it be worth adding a minimal multi-agent scenario (even a simple A delegates to B mock) to validate the agent value e2e? Otherwise LGTM on the model and registry changes.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-05-14T12:01:25Z", + "body": "Thanks @Krishnachaitanyakc - I agree we should just use `agent` and removing `direct` for the enum.\n\nMarking as Request Changes so we know it's waiting on an update from you 👍🏻", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -13999,17 +14710,18 @@ "requester": "eternalcuriouslearner", "pr_author": "Krishnachaitanyakc", "review_state": null, + "root_timestamp": "2026-05-14T22:42:49Z", "body": "@Krishnachaitanyakc Upon reading the motivation I believe the intention behind this enum is to provide visibility into delegation events. Did I get this right?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14026,17 +14738,18 @@ "requester": "AgentGymLeader", "pr_author": "Krishnachaitanyakc", "review_state": null, + "root_timestamp": "2026-06-17T10:54:34Z", "body": "Like the direction of folding handoff into `execute_tool`, and scoping `invocation.trigger` down to what's actually derivable from typed state makes sense.\n\nCouple of things:\n\n1. The delegation link lives entirely on the `execute_tool` span's `handoff.target.name`, and the receiving `invoke_agent` is a sibling, right? In a run with concurrent handoffs, or where two agents share a name, joining the edge back to the right `invoke_agent` span comes down to name matching. Did you consider a span link from `execute_tool` to the target `invoke_agent`, or a stable agent id separate from the name? The blast-radius query in the motivation feels like it'd get ambiguous on name collisions too.\n2. Since the link sits in attributes rather than parentage, if that span gets dropped by sampling you keep both `invoke_agent` spans but lose the edge between them. Is that intended?\n\nBoth are edge-case-y, so feel free to punt if it's out of scope.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14053,44 +14766,18 @@ "requester": "nikhilNava", "pr_author": "Krishnachaitanyakc", "review_state": null, + "root_timestamp": "2026-07-17T16:37:37Z", "body": "Hi @Krishnachaitanyakc - thanks for this PR.\r\n\r\n+1 to @AgentGymLeader point in https://github.com/open-telemetry/semantic-conventions-genai/pull/98#issuecomment-4729151864 about the edge relying on name matching.\r\n\r\nThe handoff creates 3 spans:\r\n\r\n1.  invoke_agent triage-agent \r\n2.  execute_tool transfer_to_billing_agent  (under 1)\r\n3.  invoke_agent billing-agent \r\n\r\nProblem: #3 sits beside #2, not under it — so no parent→child line connects the handoff to the agent it handed off to.\r\n\r\n• trace_id — shared by all spans in the run, so it can't tell which handoff went to which agent when there are several.\r\n• parent_span_id — would be the clean link, but #3's parent is the run root, not #2. So it's useless here.\r\n\r\nResult: the only way to connect them is matching the name — which breaks under concurrent handoffs or duplicate names.\r\n\r\nProposal: add  gen_ai.agent.handoff.{source,target}.id  alongside  .name mirroring  gen_ai.agent.id  on  invoke_agent , as a stable join key.\r\n\r\ncc @singankit, @trask", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4289703879", - "repo": "semantic-conventions-genai", - "pull_request": 98, - "requester": "MikeGoldsmith", - "pr_author": "Krishnachaitanyakc", - "review_state": "CHANGES_REQUESTED", - "body": "Thanks @Krishnachaitanyakc - I agree we should just use `agent` and removing `direct` for the enum.\n\nMarking as Request Changes so we know it's waiting on an update from you 👍🏻", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ "author_action", @@ -14107,17 +14794,18 @@ "requester": "trask", "pr_author": "Mandark-droid", "review_state": null, + "root_timestamp": "2026-05-11T19:15:02Z", "body": "@Mandark-droid can you fill out the new PR template? thanks! https://raw.githubusercontent.com/open-telemetry/semantic-conventions-genai/refs/heads/main/.github/PULL_REQUEST_TEMPLATE.md", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14134,17 +14822,18 @@ "requester": "trask", "pr_author": "Mandark-droid", "review_state": null, + "root_timestamp": "2026-05-11T20:10:33Z", "body": "let's add the scenario to #142, get that merged, then you can update that scenario in this PR", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14161,17 +14850,18 @@ "requester": "lmolkova", "pr_author": "Mandark-droid", "review_state": "COMMENTED", + "root_timestamp": "2026-06-06T00:39:04Z", "body": "I like where it's going, but Blob part is just one of the parts that has large content problem.\n\nI'd prefer if we\n\n- documented a configuration option that limits size of any content in any part \n- if size is exceeded we wouldn't capture it; or, for text, we would rather trim to the size\n- we could let users know that content was there by including its size on each affected part (especially blob) as you're proposing in the https://github.com/open-telemetry/semantic-conventions-genai/pull/143, but also on the text part\n- we could potentially mimic OTLP 'dropped attributes' property and record something like that on a generic part (e.g. content_dropped: true) if that's necessary (presence of non-0 size would be an indication on its own)\n\nHaving a reason seems interesting, but it's not a common approach in OTel - if something is dropped, we don't record why, it could introduce interesting problems on its own.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14188,23 +14878,24 @@ "requester": "lmolkova", "pr_author": "Jwrede", "review_state": null, + "root_timestamp": "2026-05-21T17:35:25Z", "body": "@Jwrede the suggestion is to clarify description of the existing metric in OTel to align with the spirit behind ITL (which I believe it already does). OTel metrics are independent of vLLM definitions.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", - "author_action", + "no_author_action", "author_action" ] }, @@ -14215,23 +14906,24 @@ "requester": "Cirilla-zmh", "pr_author": "Jwrede", "review_state": null, + "root_timestamp": "2026-06-09T13:29:02Z", "body": "> **\"Per-request average\" framing:** This comes from vLLM's deprecation rationale in [vllm-project/vllm#24015](https://github.com/vllm-project/vllm/pull/24015). TPOT is computed as (total_generation_time - TTFT) / (output_tokens - 1) and recorded once per request. That single value is an average over all tokens in the request.\r\n\r\nTPOT can be calculated either after all requests have returned, or in the manner of ITL as you mentioned. I believe these two approaches are essentially equivalent, at least in terms of average values. I agree with Liudmila's perspective — in my view, TPOT and ITL refer to the same concept, and if you feel that TPOT is lacking in some way, perhaps the more appropriate approach would be to enrich and extend it rather than introducing a separate metric.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", - "author_action", + "no_author_action", "author_action" ] }, @@ -14242,22 +14934,23 @@ "requester": "trask", "pr_author": "hippoley", "review_state": null, + "root_timestamp": "2026-05-26T22:12:47Z", "body": "hi @hippoley, not sure what happened, but PR content appears empty now, thanks", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "none", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", - "no_author_action", + "author_action", "author_action", "author_action" ] @@ -14269,17 +14962,18 @@ "requester": "MikeGoldsmith", "pr_author": "hippoley", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-05-28T12:20:09Z", "body": "Adding a Request Changes as changes have been lost in the last force-push", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14296,23 +14990,24 @@ "requester": "singankit", "pr_author": "hippoley", "review_state": null, + "root_timestamp": "2026-05-27T03:27:27Z", "body": "@hippoley Idea of evaluation result as event was that it can be linked to the span via traceId, spanId for any span be it invoke_agent span , chat span etc.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "no_author_action", + "author_action", "no_author_action" ] }, @@ -14323,17 +15018,18 @@ "requester": "singankit", "pr_author": "hippoley", "review_state": null, + "root_timestamp": "2026-06-04T23:20:48Z", "body": "Can you please help provide clarity on following questions:\r\n- How will evaluation span be associated to operation being evaluated?\r\n- What is evaluation span supposed to capture? The process of evaluation or evaluation results or both?\r\n- Currently evaluation results can be association with span being evaluated. After this change will evaluation result be associated with both evaluation span and span being evaluated?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14350,17 +15046,18 @@ "requester": "hippoley", "pr_author": "RKest", "review_state": null, + "root_timestamp": "2026-05-26T02:56:28Z", "body": "The `invoke_node` span fills a real gap — in multi-agent workflows the current span hierarchy jumps from `invoke_workflow` directly to `invoke_agent` or `execute_tool`, with no way to represent intermediate processing nodes (validators, routers, formatters, etc.).\n\nThe design is consistent with the existing `gen_ai.execute_tool.internal` / `gen_ai.plan.internal` pattern, which is good. A few observations:\n\n1. **Naming**: `invoke_node` reads naturally alongside `invoke_agent` and `invoke_workflow`. The `gen_ai.node.name` attribute is clean.\n\n2. **Relationship to `gen_ai.evaluation.internal`**: I have an open PR (#185) that adds a similar `gen_ai.evaluation.internal` span for evaluation steps. Both follow the same `gen_ai..internal` pattern. It might be worth a quick cross-check to make sure the attribute sets are consistent (both use `gen_ai.operation.name` as required, `gen_ai.agent.name` as conditionally required, etc.).\n\n3. **`gen_ai.client.workflow.node.invocation.details` event**: the name is quite long. Is there a shorter form that still conveys the scope? Something like `gen_ai.node.invocation.details` might be easier to type and remember.\n\nOverall this is a solid ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14377,17 +15074,18 @@ "requester": "trask", "pr_author": "RKest", "review_state": null, + "root_timestamp": "2026-05-27T01:29:41Z", "body": "hi @RKest, can you mark this as \"Resolves #187\" (assuming it does)? thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14404,24 +15102,25 @@ "requester": "lmolkova", "pr_author": "RKest", "review_state": "COMMENTED", + "root_timestamp": "2026-07-07T01:00:59Z", "body": "Looks good, just a few comments", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", - "no_author_action" + "author_action" ] }, { @@ -14431,22 +15130,23 @@ "requester": "lmolkova", "pr_author": "RKest", "review_state": "COMMENTED", + "root_timestamp": "2026-07-23T03:11:24Z", "body": "I support the PR - it helps us cover operations that are not categorized yet.\n\nNow bikeshed time: *node* vs *step* vs *task* \n\n## Agent frameworks\n\n| lib | native term | concerns with \"node\" | concerns with \"step\" | concerns with \"task\" |\n|---|---|---|---|---|\n| langchain (LangGraph) | node | 🟢 none — native | foreign, no collision | overloaded (generic) |\n| google-adk 2.0 | node + edge | 🟢 none — native | 🟢 none — ADK calls a node \"a single step\" | overloaded (generic) |\n| pydantic-ai (pydantic-graph) | node (BaseNode) | 🟢 none — native | foreign, no collision | overloaded (generic) |\n| autogen (GraphFlow) | node (= agent) | 🟢 none — native | foreign | wrong level — task = the input/overall job |\n| agent-framework (MAF) | executor + edge | foreign | foreign | overloaded (generic) |\n| haystack (Pipeline) | component | 🔴 deprecated v1 term | foreign | overloaded (generic) |\n| llamaindex (Workflows) | step (@step) | 🔴 collides with Node/TextNode | 🟢 none — native | 🔴 collides with Task/TaskStep (core agent API) |\n| crewai | step (Flow); Task (Crew) | foreign | 🟢 none — native (Flow) | 🔴 collides with Task (core class) |\n| dspy | module (forward) | quite foreign | foreign | overloaded ...[truncated]", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "no_author_action", - "no_author_action", + "author_action", + "author_action", "author_action", "author_action" ] @@ -14458,17 +15158,18 @@ "requester": "JWinermaSplunk", "pr_author": "eternalcuriouslearner", "review_state": null, + "root_timestamp": "2026-06-08T16:22:44Z", "body": "Hi @eternalcuriouslearner,\r\nThis is a rather large PR, is there any way we could break this down into separate PRs? Perhaps \"Spans and Attributes\", \"Metrics\", and \"Reference Scenarios\"? Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14485,17 +15186,18 @@ "requester": "trask", "pr_author": "eternalcuriouslearner", "review_state": null, + "root_timestamp": "2026-06-08T22:46:00Z", "body": "Reference scenarios should live with the relevant semconv PR, since we use them to evaluate the semconv changes themselves.\r\n\r\nmaybe\r\n\r\n- Core A2A attributes + spans\r\n- Operation duration + response body size metrics\r\n- Streaming metrics", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14512,17 +15214,18 @@ "requester": "pwkowalski", "pr_author": "eternalcuriouslearner", "review_state": null, + "root_timestamp": "2026-06-08T22:56:58Z", "body": "Hey @eternalcuriouslearner,\r\nI've recently opened a more exhaustive proposal for A2A semantic conventions #254 (previous one was #70) and I'd like to align with you on that since the issue is still untriaged AFAIK. It seems compatible for the most part, with only some minor differences.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14539,17 +15242,18 @@ "requester": "aabmass", "pr_author": "eternalcuriouslearner", "review_state": null, + "root_timestamp": "2026-06-09T02:07:34Z", "body": "Thanks Surya. Let me know when this PR is ready for another look. Maybe we can split up a few PRs between yourself and @pwkowalski ?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14566,24 +15270,25 @@ "requester": "pwkowalski", "pr_author": "eternalcuriouslearner", "review_state": null, + "root_timestamp": "2026-06-09T05:21:29Z", "body": "I'd be happy to work on the implementation if it doesn't introduce unnecessary overhead - I wouldn't want to disrupt the workflow. So if there's some way I could help, please let me know.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -14593,17 +15298,18 @@ "requester": "pwkowalski", "pr_author": "eternalcuriouslearner", "review_state": null, + "root_timestamp": "2026-06-12T13:03:49Z", "body": "Hey @eternalcuriouslearner, thanks for your hard work!\r\n\r\nI agree about the removal of `gen_ai.agent.name` and `gen_ai.agent.id`, I've documented it in #254 already. I think it should be a follow-up once #243 is decided, in order to not block work.\r\n\r\n`a2a.client.response.time_to_first_event` seems to be aligned with `gen_ai.client.operation.time_to_first_chunk` - is the server one actually necessary?\r\n\r\n`a2a.client.response.body.size` seems dependent on transport method. Not sure it should be there.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14614,23 +15320,24 @@ ] }, { - "id": "pr-issue-comment-4718881332", + "id": "pr-review-4505106672", "repo": "semantic-conventions-genai", "pull_request": 195, "requester": "pwkowalski", "pr_author": "eternalcuriouslearner", - "review_state": null, - "body": "I'm also not sure about these method names in general - A2A doesn't define them per se, but uses Pascal Case. However, I think a good reason to keep them like that (`message/send` instead of `SendMessage`) is keeping them aligned with existing MCP semconv method names.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-16T10:58:31Z", + "body": "Looks good, had some feedback but it should be minor.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -14641,77 +15348,108 @@ ] }, { - "id": "pr-issue-comment-4740216360", + "id": "pr-issue-comment-4718881332", "repo": "semantic-conventions-genai", "pull_request": 195, "requester": "pwkowalski", "pr_author": "eternalcuriouslearner", "review_state": null, - "body": "Sorry for the slight delay @eternalcuriouslearner.\r\n\r\nFollowing up on \"splitting up the work\" from earlier, is there something I could help with?", + "root_timestamp": "2026-06-16T12:46:29Z", + "body": "I'm also not sure about these method names in general - A2A doesn't define them per se, but uses Pascal Case. However, I think a good reason to keep them like that (`message/send` instead of `SendMessage`) is keeping them aligned with existing MCP semconv method names.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "author", - "author", - "author", - "author" + "author_action", + "no_author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", "author_action", + "no_author_action", "author_action", "author_action", "author_action" ] }, { - "id": "pr-issue-comment-4748596228", + "id": "pr-review-4507167174", "repo": "semantic-conventions-genai", "pull_request": 195, - "requester": "AgentGymLeader", + "requester": "pwkowalski", "pr_author": "eternalcuriouslearner", - "review_state": null, - "body": "One modeling question on the core attrs, while this one's getting wrapped up: `a2a.message.referenced_task_ids` and `a2a.task.artifact_ids` are ID arrays pointing at other operations. Have you weighed span links for the task references instead of an ID-array attribute? If a referenced task is itself a span, a link keeps the causal edge queryable without baking high-cardinality arrays into attributes. Artifacts probably stay fine as attributes since they aren't spans. Referenced tasks feel link-shaped though.\n\nNot blocking the split work. Just worth settling deliberately while the core set is still being shaped, and probably in the #254 alignment too.", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-16T14:06:09Z", + "body": "Sorry, one more thing I've noticed after re-reading.", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ + "no_author_action", + "author_action", "author_action", "author_action", + "author_action" + ] + }, + { + "id": "pr-issue-comment-4740216360", + "repo": "semantic-conventions-genai", + "pull_request": 195, + "requester": "pwkowalski", + "pr_author": "eternalcuriouslearner", + "review_state": null, + "root_timestamp": "2026-06-18T09:19:02Z", + "body": "Sorry for the slight delay @eternalcuriouslearner.\r\n\r\nFollowing up on \"splitting up the work\" from earlier, is there something I could help with?", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "no_author_action", + "no_author_action", + "no_author_action", "author_action", + "author_action" + ], + "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", "author_action", "author_action" ] }, { - "id": "pr-issue-comment-4763413140", + "id": "pr-issue-comment-4748596228", "repo": "semantic-conventions-genai", "pull_request": 195, "requester": "AgentGymLeader", "pr_author": "eternalcuriouslearner", "review_state": null, - "body": "@eternalcuriouslearner yeah, that layered split sounds right to me. `referenced_task_ids` is what instrumentation can always read straight off the payload, so it makes sense as the core attribute. The span link is the better causal edge, but you can only build it when the referenced task's span context is actually resolvable, which generic instrumentation often won't have.\n\nOnly tweak I'd suggest: instead of leaving the link purely optional, word it as \"emit a link when the context is resolvable.\" That keeps the queryable causal edge I was after originally, without forcing anything on instrumentation that only has the IDs.\n\nThe deciding factor is the SDK side though, so I'll leave that call to @pwkowalski: for a2a-python, do we actually get span/trace context for the tasks in `referenceTaskIds`, or just the IDs from the payload?", + "root_timestamp": "2026-06-19T04:53:23Z", + "body": "One modeling question on the core attrs, while this one's getting wrapped up: `a2a.message.referenced_task_ids` and `a2a.task.artifact_ids` are ID arrays pointing at other operations. Have you weighed span links for the task references instead of an ID-array attribute? If a referenced task is itself a span, a link keeps the causal edge queryable without baking high-cardinality arrays into attributes. Artifacts probably stay fine as attributes since they aren't spans. Referenced tasks feel link-shaped though.\n\nNot blocking the split work. Just worth settling deliberately while the core set is still being shaped, and probably in the #254 alignment too.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14722,50 +15460,52 @@ ] }, { - "id": "pr-issue-comment-4769602307", + "id": "pr-issue-comment-4763413140", "repo": "semantic-conventions-genai", "pull_request": 195, - "requester": "aabmass", + "requester": "AgentGymLeader", "pr_author": "eternalcuriouslearner", "review_state": null, - "body": "> > I'm also not sure about these method names in general - A2A doesn't define them per se, but uses Pascal Case. However, I think a good reason to keep them like that (`message/send` instead of `SendMessage`) is keeping them aligned with existing MCP semconv method names.\r\n> \r\n> Howdy @aabmass can you pitch in here. Should we use pascal case or keep it as `message/send`?\r\n\r\nThese are attributes values right? IMO we should copy what's in the protocol so keeping the pascal case, see the generic RPC conventions https://opentelemetry.io/docs/specs/semconv/registry/attributes/rpc/#rpc-method", + "root_timestamp": "2026-06-21T21:58:54Z", + "body": "@eternalcuriouslearner yeah, that layered split sounds right to me. `referenced_task_ids` is what instrumentation can always read straight off the payload, so it makes sense as the core attribute. The span link is the better causal edge, but you can only build it when the referenced task's span context is actually resolvable, which generic instrumentation often won't have.\n\nOnly tweak I'd suggest: instead of leaving the link purely optional, word it as \"emit a link when the context is resolvable.\" That keeps the queryable causal edge I was after originally, without forcing anything on instrumentation that only has the IDs.\n\nThe deciding factor is the SDK side though, so I'll leave that call to @pwkowalski: for a2a-python, do we actually get span/trace context for the tasks in `referenceTaskIds`, or just the IDs from the payload?", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { - "id": "pr-issue-comment-4769751764", + "id": "pr-issue-comment-4769602307", "repo": "semantic-conventions-genai", "pull_request": 195, "requester": "aabmass", "pr_author": "eternalcuriouslearner", "review_state": null, - "body": "> @AgentGymLeader Good point. I’m trying to reason through how feasible this is for generic A2A instrumentation.\r\n\r\n+1 on making sure it's feasible to instrument. Let's push this to a follow up PR if nothing is blocking, I think regardless we should capture the `referenced_task_ids` which are sent on the wire.\r\n\r\n@AgentGymLeader can you file a follow up issue for documenting downstream span linking?", + "root_timestamp": "2026-06-22T14:52:05Z", + "body": "> > I'm also not sure about these method names in general - A2A doesn't define them per se, but uses Pascal Case. However, I think a good reason to keep them like that (`message/send` instead of `SendMessage`) is keeping them aligned with existing MCP semconv method names.\r\n> \r\n> Howdy @aabmass can you pitch in here. Should we use pascal case or keep it as `message/send`?\r\n\r\nThese are attributes values right? IMO we should copy what's in the protocol so keeping the pascal case, see the generic RPC conventions https://opentelemetry.io/docs/specs/semconv/registry/attributes/rpc/#rpc-method", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14776,52 +15516,29 @@ ] }, { - "id": "pr-review-4505106672", + "id": "pr-issue-comment-4769751764", "repo": "semantic-conventions-genai", "pull_request": 195, - "requester": "pwkowalski", + "requester": "aabmass", "pr_author": "eternalcuriouslearner", - "review_state": "CHANGES_REQUESTED", - "body": "Looks good, had some feedback but it should be minor.", + "review_state": null, + "root_timestamp": "2026-06-22T15:06:28Z", + "body": "> @AgentGymLeader Good point. I’m trying to reason through how feasible this is for generic A2A instrumentation.\r\n\r\n+1 on making sure it's feasible to instrument. Let's push this to a follow up PR if nothing is blocking, I think regardless we should capture the `referenced_task_ids` which are sent on the wire.\r\n\r\n@AgentGymLeader can you file a follow up issue for documenting downstream span linking?", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4507167174", - "repo": "semantic-conventions-genai", - "pull_request": 195, - "requester": "pwkowalski", - "pr_author": "eternalcuriouslearner", - "review_state": "CHANGES_REQUESTED", - "body": "Sorry, one more thing I've noticed after re-reading.", - "role": "context", - "stability": null, - "recorded_label": null, - "adjudicated_label": null, - "run_actions": [ - null, - null, - "none", - "none", - null ], "run_labels": [ + "no_author_action", + "no_author_action", + "no_author_action", "no_author_action", "no_author_action" ] @@ -14833,17 +15550,18 @@ "requester": "aabmass", "pr_author": "eternalcuriouslearner", "review_state": "COMMENTED", + "root_timestamp": "2026-06-25T22:42:55Z", "body": "Looks great, thank you! The only real blocking question I have is on the inclusion of http or RPC span attributes.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14860,17 +15578,18 @@ "requester": "Nik-Reddy", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-05-26T20:15:43Z", "body": "@trask Read through the full PR including the FAQ and alternatives.\r\n Three questions on the choices made, framed against the three points I was planning to surface at SIG this week before #197 landed:\r\n \r\n **Three counters vs one with all axes.** The FAQ explains the cross-product issue cleanly: providers report cache and phase marginally, not jointly with modality, so a single counter with all four dimensions would force producers to invent cross-product cells they don't actually have. Accepting that. One follow-up: the three-counter split means `sum(inference.tokens)` and `sum(input_tokens_by_cache)` should reconcile on input total, and consumers will likely write queries that subtract or compare across them. Is it worth documenting the invariant explicitly in the metric description so downstream dashboards can rely on it (e.g. \"sum over `input_tokens_by_cache.cache` equals sum over inference.tokens where token.type=input\")?\r\n \r\n **Modality value set consistency.** `gen_ai.token.modality` uses `text | image | audio | video | document | unknown`. The existing `gen_ai.output.type` uses `text | json | image | speech` and the message-part schemas use `image | video | audio | docum ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14880,6 +15599,34 @@ "author_action" ] }, + { + "id": "pr-review-4368707323", + "repo": "semantic-conventions-genai", + "pull_request": 197, + "requester": "lmolkova", + "pr_author": "trask", + "review_state": "COMMENTED", + "root_timestamp": "2026-05-27T02:01:43Z", + "body": "Wow, thanks for this proposal! Made a first pass with some questions", + "role": "scored", + "stability": "flaky", + "recorded_label": null, + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "no_author_action", + "no_author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "no_author_action", + "no_author_action", + "author_action" + ] + }, { "id": "pr-issue-comment-4553113123", "repo": "semantic-conventions-genai", @@ -14887,17 +15634,18 @@ "requester": "alexmojaki", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-05-27T09:09:02Z", "body": "> and reasoning output (priced separately from response output on o-series and Gemini 2.5+).\r\n\r\nPeople do want to track reasoning tokens, but I don't think they have their own pricing on current models, and if I'm wrong I'd love to know.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -14914,17 +15662,18 @@ "requester": "chightow", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-05-30T13:26:30Z", "body": "\"Reasoning\" tokens as far as I know aren't priced differently, they are important to track as the scratch work often ends up being a large differentiator of cost between different models ex.\n\nOpus 4.5, 4.6 , 4.7, 4.8 for example all currently priced the same main differentiator in cost I've observed has been the extent to which the models are configured to aggressively use the \"reasoning\" block revealing this to end users in an easy way to show what \"reasoning\" is costing them and to help them make the determination if the \"reasoning\" provides any value to a given use case.\n\nThank you for this pr from downstream \n\nIt should greatly simplify observability.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -14941,22 +15690,23 @@ "requester": "lmolkova", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-06-04T22:10:54Z", "body": "We're going to discuss this on an ad-hoc call tomorrow at 12pm PT: [Calendar](https://calendar.google.com/calendar/u/0/r/day/2026/6/5?eid=MnI0NDloamxmdGU3b2ZnYXNsYzR1ZmZoZ2wgY18yYmY3M2UzYjZiNTMwZGE0YmFiZDQ0NGU3MmI3NmE2YWQ4OTNhNWMzZjQzY2Y0MDQ2N2FiYzdhOWE4OTdmOTc3QGc), [Zoom](https://zoom.us/j/91357539844?pwd=MU9ZRUNyVUwrcHdiclU2b2lPOVBkQT09).\r\n\r\nPlease join if you can @alexmojaki @Nik-Reddy @aabmass @trask", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "author_action", + "author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", + "no_author_action", + "no_author_action", + "no_author_action", "author_action", "author_action" ] @@ -14968,24 +15718,25 @@ "requester": "alexmojaki", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-06-05T18:16:30Z", "body": "> making cost queries that match the provider pricing structure (per-modality, per-cache-state unit prices) answerable from metrics alone\r\n\r\ncosts can't be calculated from metrics in general anyway since the price per token often depends on the number of (input) tokens in a request, unless you added another metric attribute indicating the pricing bucket.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "none", - "author", - "none", - "none", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "no_author_action", "author_action", - "no_author_action", - "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action", + "author_action" ] }, { @@ -14995,50 +15746,25 @@ "requester": "alexmojaki", "pr_author": "trask", "review_state": null, + "root_timestamp": "2026-06-05T18:29:23Z", "body": "> Why don't gen_ai.token.modality and gen_ai.output.type use the same enum values?\r\n\r\nwas this removed?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ "author_action", "author_action", "author_action", "author_action", "author_action" - ] - }, - { - "id": "pr-review-4368707323", - "repo": "semantic-conventions-genai", - "pull_request": 197, - "requester": "lmolkova", - "pr_author": "trask", - "review_state": "COMMENTED", - "body": "Wow, thanks for this proposal! Made a first pass with some questions", - "role": "context", - "stability": null, - "recorded_label": null, - "adjudicated_label": null, - "run_actions": [ - "none", - "author", - "author", - null, - "none" ], "run_labels": [ - "no_author_action", "author_action", "author_action", - "no_author_action" + "author_action", + "author_action", + "author_action" ] }, { @@ -15048,17 +15774,18 @@ "requester": "MikeGoldsmith", "pr_author": "singankit", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-08T13:52:56Z", "body": "Since Bedrock support isn't wired up to the right field yet, should remove the scenario until it does support it?\n\nAlso, I believe `invoke_agent.common` should be `invoke_agent.client`", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15075,17 +15802,18 @@ "requester": "eternalcuriouslearner", "pr_author": "singankit", "review_state": null, + "root_timestamp": "2026-06-07T22:36:15Z", "body": "@singankit Can we add some test scenarios for this?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15102,17 +15830,18 @@ "requester": "Nik-Reddy", "pr_author": "singankit", "review_state": null, + "root_timestamp": "2026-06-14T08:39:18Z", "body": "Thanks for porting this. One clarification that would help implementers: when an agent service already emits an HTTP/RPC server span for the incoming request, should **gen_ai.invoke_agent.server** be emitted as a child span for the agent operation boundary? A short note or reference scenario would make this easier to apply consistently across SDKs and hosted agent services.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15129,17 +15858,18 @@ "requester": "AgentGymLeader", "pr_author": "nagkumar91", "review_state": null, + "root_timestamp": "2026-06-08T22:41:28Z", "body": "@nagkumar91 this is a solid shape. The verdict-vs-action split is the right call — keeping \"what the guardrail returned\" separate from \"what the caller actually enforced\" matches how these break in practice (a framework can return block and the caller still lets it through, and you want both on the trace).\n\nTwo things I'd pin down while it's still in development:\n\n1. The blocked case should be readable from absence, not only from the finding event. If a guardrail returns block and the caller enforces it before the operation runs, the guarded op should have no success span. A terminal block plus no downstream execute span is what lets a reader tell \"blocked\" apart from \"never ran\" or \"telemetry got dropped.\" Worth stating normatively how the guardrail span and finding link back to the operation they gated (a span relationship, not just a shared trace), so the block and the missing span are tied together. This also lines up with the span-relationship discussion in #243.\n\n2. Keep external_finding_id an opaque, producer-defined correlation handle, and keep the finding record itself out of scope. The convention should define a reference you can join on (SIEM, incident, etc.), not reach ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15156,17 +15886,18 @@ "requester": "aabmass", "pr_author": "nagkumar91", "review_state": null, + "root_timestamp": "2026-06-11T17:07:03Z", "body": "Hey @nagkumar91, does this address the feedback we went through in the call and in [this doc](https://docs.google.com/document/d/14CD0_ApP0W_ek9VNJN1N_2Bz5ifiJ978LTv5AD4mf_o/edit?tab=t.0)? Just lmk and I'll review and get someone from Model Armor to review.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15183,17 +15914,18 @@ "requester": "Rul1an", "pr_author": "nagkumar91", "review_state": null, + "root_timestamp": "2026-06-11T18:02:14Z", "body": "Strong direction, and the privacy posture is already careful: `content.input.value`/`.output.value` are opt_in with sensitive-content warnings, `finding.evidence` is a non-content channel with a MUST NOT on sensitive data, and `verdict.type` (what the guardrail returned) is kept separate from `action.type` (what the caller enforced). Those boundaries are right, and the `run_guardrail.client` vs `.internal` split captures out-of-process vs in-process cleanly.\n\n`gen_ai.security.content.input.hash` is the field everyone gets pointed to as the privacy-preserving path, and as written it doesn't pin what it hashes. Its purpose is forensic correlation, but that only works if two implementations agree on the exact bytes and the algorithm, and \"hash of the input content\" leaves open the encoding, any normalization, and what the input even is for a structured `tool_call_input` (a JSON object, not a string). Two services inspecting the same content can produce different hashes, so the field can't do its one job.\n\nSmall fix: name a canonical byte form plus a hash. For structured targets, RFC 8785 (JCS) over the arguments object then SHA-256; for free-text, state UTF-8 and any normalization. Th ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15210,22 +15942,23 @@ "requester": "Rul1an", "pr_author": "nagkumar91", "review_state": null, + "root_timestamp": "2026-06-15T17:32:55Z", "body": "This is the right shape now: tagging the algorithm, naming the canonical byte form, and splitting text (UTF-8 plus a stated normalization) from structured (deterministic serialization for a tool_call) is what lets the hash do its forensic-correlation job. The piece that keeps it working across two implementations is a named default per target subtype, not only a tag: if each service tags whatever it used, two inspectors of the same tool_call still diverge, so one default canonical form plus algorithm per subtype (JCS then SHA-256 for tool_call, UTF-8 with a named normalization then SHA-256 for text) makes an unkeyed hash reproducible without coordination. The HMAC path for sensitive content is the right call; it correlates within a shared-key domain rather than across orgs, which is the honest bound to state alongside it.\n\nIf useful I can add two worked examples as a small follow-up, one tool_call and one free-text, with the exact bytes and resulting digest so a second implementation reproduces them from the example alone. Glad to keep it out of this review if you'd rather land the convention first.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "author", - "none" + "no_author_action", + "author_action", + "no_author_action", + "author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", "author_action", + "no_author_action", "author_action", "no_author_action" ] @@ -15237,22 +15970,23 @@ "requester": "Rul1an", "pr_author": "nagkumar91", "review_state": null, + "root_timestamp": "2026-06-15T17:55:25Z", "body": "Here are the two worked examples, reproducible from the bytes alone.\n\nStructured (`tool_call`), RFC 8785 (JCS) over the input object then SHA-256:\n\n- input: `{\"name\":\"query_table\",\"arguments\":{\"table\":\"employees\",\"limit\":10}}`\n- canonical bytes: `{\"arguments\":{\"limit\":10,\"table\":\"employees\"},\"name\":\"query_table\"}`\n- `sha256:40cfbce5aa3b2794c73996f4db4e6c2b45a5492cdc2a4bc71773e88eeebc3d95`\n\nFree-text, Unicode NFC then UTF-8 then SHA-256, on `café au lait`:\n\n- normalized bytes (hex): `636166c3a9206175206c616974`\n- `sha256:7c413039fbb2248e2b18b98e7a8d4d85bdcac7cd79b9477a0923f97e3a1f2b50`\n- the same text as NFC and as NFD (`e` + U+0301) both reach that digest once NFC-normalized; the raw NFD bytes hash to `sha256:2f97bdcfe9d8165b6d25df3f56d7b83e16637d199505d01eff4a3e94eb1d9e15` instead, which is why the normalization has to be named rather than implementation-defined.\n\nThe JCS recipe is exact for objects of strings and integers; floating-point values would also need RFC 8785 number formatting. Happy to drop these into the reference scenario or a doc example, whichever you prefer.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", - "author_action", + "no_author_action", + "no_author_action", "no_author_action", "no_author_action" ] @@ -15264,17 +15998,18 @@ "requester": "AgentGymLeader", "pr_author": "nagkumar91", "review_state": null, + "root_timestamp": "2026-06-26T00:14:27Z", "body": "On correlation, I'd keep the shape from #132: alongside `external_finding_id` (SIEM-facing), keep a producer-side correlation that stays opaque and producer-defined, so the span stays lean and the heavier context lives in the producer's own store, joined by id at audit time. I'd leave the external record format unspecified rather than mandate a canonical form.\n\nOn `escalate`: it works well as a real \"doesn't proceed yet\" decision. Worth saying the later resolution (allow or block by a human or external workflow) is a separate event rather than an overwrite, so both the decision-time state and the outcome survive.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15291,17 +16026,18 @@ "requester": "lmolkova", "pr_author": "nagkumar91", "review_state": "COMMENTED", + "root_timestamp": "2026-07-05T20:03:13Z", "body": "Could you please list the systems that were evaluated (that could be instrumented with run_guardrail span) and share research on which properties they have and how they map to attributes being defined.\n\nIt seems we don't have any scenarios that would show how auto-instrumentation can record this span - are there any open source libraries or clients for server-side guardrails that can be instrumented and then can we add them to reference scenarios?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15318,17 +16054,18 @@ "requester": "MikeGoldsmith", "pr_author": "AgentGymLeader", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-17T15:03:27Z", "body": "Nice work @AgentGymLeader - I think this is a good start.\n\nI've left a couple of comments & suggestions. I think it's worth adding tests for the new parsing/counting paths so regressions get caught too.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15345,24 +16082,25 @@ "requester": "JWinermaSplunk", "pr_author": "AgentGymLeader", "review_state": "COMMENTED", + "root_timestamp": "2026-06-22T17:57:48Z", "body": "Left a few comments, mainly wondering about the previous comment, as we can still derive token usage and operation duration from the existing span.", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "author", - "none" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "no_author_action", "author_action", "author_action", - "no_author_action" + "author_action", + "author_action" ] }, { @@ -15372,17 +16110,18 @@ "requester": "meshailabs", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-15T21:22:15Z", "body": "The namespace form is the right call. `gen_ai.agent.drift_score` acting as both a key and the parent of `...drift_score.method` has no precedent in the registry and trips the policy check, as you noted. `gen_ai.agent.{trust,drift}.{score,method}` and `gen_ai.agent.scan.{verdict,method}` validate cleanly and keep each score visibly paired with its method token. No objection to the rename from our side; the semantics are unchanged.\n\nOn Recommended vs Opt-In: Recommended wherever the corresponding score is emitted is correct. A producer-scoped score is close to uninterpretable to a consumer correlating against outcomes without knowing the method epoch that produced it, and the cardinality cost is low since the token only moves on a re-fit or re-threshold, not per span. Opt-In would let a producer emit the score without the token, which is the exact failure mode the token exists to prevent.\n\nOne addition worth pinning in the attribute notes: state explicitly that the `.method` token is opaque and compared for equality only, with no consumer parsing of the method or version substructure. That keeps producers free to change their internal versioning without consumers building brittle par ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15399,17 +16138,46 @@ "requester": "giskard09", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-16T14:27:39Z", "body": "Picking up from the gap I noted in #180 (comment above, today) — after the PR merges, one gap remains: the eight attributes are all producer-scoped. A consumer comparing spans across producers, or auditing a single producer's records without trusting that producer, has no recomputable handle.\n\nProposing a ninth attribute to close it:\n\n`gen_ai.agent.action_ref`\n- type: string\n- brief: SHA-256 of the JCS-canonical (RFC 8785) preimage `{agent_id, action_type, scope, timestamp_ms}` per action-ref-v1.\n- requirement_level: recommended\n- note: A deterministic, cross-producer correlation key. Any implementation that follows the derivation produces the same 32-byte hex digest from the same preimage fields — no service call required (no_giskard_api invariant). A verifier comparing records across producers, or auditing without trusting the emitting producer, can recompute it independently.\n\nThe `.method` companion tokens (`trust.method`, `drift.method`, `scan.method`) handle within-producer stability. This attribute handles the cross-producer case.\n\nNormative reference: draft-giskard-aeoess-action-ref-00\nhttps://github.com/giskard09/draft-giskard-aeoess-action-ref\n\nThree independent productio ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" + ] + }, + { + "id": "pr-review-4559593502", + "repo": "semantic-conventions-genai", + "pull_request": 291, + "requester": "lmolkova", + "pr_author": "thebenignhacker", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-06-24T06:22:55Z", + "body": "could you please add reference scenarios showing which instrumentation can capture these attributes, how they would do it, and which signals these attributes would appear on? Check out https://github.com/open-telemetry/semantic-conventions-genai/blob/main/CONTRIBUTING.md#4-update-reference-scenarios for the details", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", + "adjudicated_label": null, + "run_actions": [ + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15426,17 +16194,18 @@ "requester": "chopmob-cloud", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-24T19:46:47Z", "body": "Thank you, good to see this moving forward. If there is anything else we can help with, please just shout.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15453,17 +16222,18 @@ "requester": "meshailabs", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-24T20:12:14Z", "body": "+1 to the inline note on the method tokens. A score and its `.method` token are one unit: a score emitted without the token that produced it is close to uninterpretable to a consumer correlating against outcomes, because they cannot tell a re-fit or re-threshold from a real move in the agent. A flat `opt_in` on the token permits exactly that, a producer emitting the score and dropping the token, which is the failure the token exists to prevent.\n\nTying each token to its score reads cleaner than a blanket opt_in: recommend (or conditionally require) `gen_ai.agent.trust.method` when `gen_ai.agent.trust.score` is set, and the same for drift and scan. The registry notes already say recommended wherever the score is emitted, so this just lines the span requirement level up with the note. The token only moves on a method change, not per span, so the cardinality cost stays low.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15480,17 +16250,18 @@ "requester": "aeoess", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-25T05:49:39Z", "body": "The attributes here are not things a GenAI framework's `invoke_agent` instrumentation can populate on its own. Instrumentation around the model call, the tools, and the response only sees what the model and the immediate execution environment produce. It does not see the agent's authorized capability, its trust or drift signals, or a scan verdict, because none of those are properties of the inference itself. They are outputs of whatever component made the authorization decision: a policy decision point, an agent gateway, or a governance layer sitting in front of the action.\n\nThat component already computes, or has access to, the capability being invoked, the authority or delegation basis the decision was measured against, and any producer-scoped trust, drift, or scan signals, as part of making its allow or deny decision. The instrumentation that populates these span attributes is therefore instrumentation of that decision, emitted on the `invoke_agent` span or correlated to it. The values come from the decision context, not from the model call and not from constants.\n\nThat is also why hardcoding the values does not demonstrate real instrumentation. A more useful scenario would mode ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15507,17 +16278,18 @@ "requester": "giskard09", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-25T10:04:31Z", "body": "`argentum-core` implements the authorization gate that produces these values. The capability, trust/drift signals, and scan verdict are outputs of that gate's decision — the gate computes them and the instrumentation sets the span attributes from the returned decision object, not from the invocation framework.\n\nRunnable examples: `giskard09/argentum-core/examples/conformance/`", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15534,17 +16306,18 @@ "requester": "meshailabs", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-25T13:01:32Z", "body": "@lmolkova you are right to push on this. The hardcoded values are a fair criticism of the scenario as written. To your question: yes, there is a real component, and it is not the model-call instrumentation. @aeoess described it well: these attributes are outputs of whatever made the authorization decision, a policy decision point, an agent gateway, or a governance layer in front of the action. The inference instrumentation never sees a trust or drift signal, because none of them are properties of the inference.\n\nWe work on the producer side of this, a control-plane layer that sits in front of agent actions, so this is the vantage point we see it from. The deciding component already holds the capability, the trust and drift signals, and the scan verdict, since those are the inputs to its allow or deny decision. The instrumentation that populates these attributes is instrumentation of that decision, correlated onto the `invoke_agent` span, not of the model call.\n\nFor the scenario, a minimal authorization step that returns a decision object, with the span attributes set from that returned decision rather than from literals, would show both the instrumentation point (the gate) and the ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15561,17 +16334,18 @@ "requester": "lmolkova", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-26T00:43:26Z", "body": "> these attributes are outputs of whatever made the authorization decision\r\n\r\nIf this is a shared library or component, please share the details about it. There seem to be no auto-instrumentations or infra pieces that are able to report it today, so it's not in scope of this project to cover such conventions. You can document them for your own app.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15588,17 +16362,18 @@ "requester": "AgentGymLeader", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-26T05:08:07Z", "body": "On \"is there a real component\" — I came across one in AGT: microsoft/agent-governance-toolkit#3190 wires decision events (allow/deny/warn…) over OTel across its SDKs, under an `acs_*` namespace. Whether that's in scope here or just app-level is your call — flagging it as a concrete producer in case it helps.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15615,23 +16390,24 @@ "requester": "lmolkova", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-26T14:30:46Z", "body": "> On \"is there a real component\" — I came across one in AGT: [microsoft/agent-governance-toolkit#3190](https://github.com/microsoft/agent-governance-toolkit/pull/3190) wires decision events (allow/deny/warn…) over OTel across its SDKs, under an `acs_*` namespace. Whether that's in scope here or just app-level is your call — flagging it as a concrete producer in case it helps.\r\n\r\nThanks, this is a useful context! If there is a second example of a shared component, the path forward would be to:\r\n\r\n1. Decide which operations should be instrumented (not attributes emitted on arbitrary spans). Agent-level instrumentation won't have access to this information, so stamping on agent spans can't be done with auto-instrumentation\r\n2. Add reference scenarios for applicable shared components\r\n3. Think broad about agent identity and governance and how to model it in general rather than about a handful of attributes", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" - ], - "run_labels": [ + "no_author_action", "author_action", "author_action", + "no_author_action", + "author_action" + ], + "run_labels": [ + "no_author_action", "author_action", "author_action", + "no_author_action", "author_action" ] }, @@ -15642,17 +16418,18 @@ "requester": "giskard09", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-26T14:50:50Z", "body": "Building on my prior comment on the gate as producer —\n\nThe connection to AGT#3190 is direct: that PR defines `acs_intervention_{allow,deny,warn,escalate,transform}_total` counters per evaluation and explicitly omits `action_identity`. The gap it leaves: the counter records how many interventions occurred, not which specific action was decided on. `action_ref` fills that field — SHA-256(JCS({agent_id, action_type, scope, timestamp})) — recomputable by any downstream verifier without trusting the emitting component.\n\nOn the path you've outlined:\n\n**Operations to instrument** — the gate's evaluation call, not an agent span. We added §Telemetry Integration to the working draft today ([f3628b7](https://github.com/giskard09/draft-etcheverry-action-ref/commit/f3628b769d0ba953f1f53237e6c9b95801361606)) that formalizes this: \"Implementations MUST NOT derive action_ref at the invoking agent's span level. Agent-level instrumentation does not have access to the complete intent tuple as presented to the gate.\" The gate derives the value before returning the verdict; downstream spans carry it as a correlation key.\n\n**Reference scenarios** — [draft-etcheverry-action-ref](https://datatracker.ietf ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15669,24 +16446,25 @@ "requester": "lmolkova", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-06-26T14:56:51Z", "body": "@giskard09 I would not recommend bulk AI-generating semantic convention proposal for governance. It needs a lot of human judgement.", "role": "scored", - "stability": "stable", - "recorded_label": "no_author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", + "author_action", + "author_action", + "author_action" + ], + "run_labels": [ "no_author_action", "no_author_action", - "no_author_action" + "author_action", + "author_action", + "author_action" ] }, { @@ -15696,17 +16474,18 @@ "requester": "AgentGymLeader", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-07-01T15:56:22Z", "body": "@thebenignhacker A first cut as the decision operation sounds right. On the enum/metric shape you'd coordinate cross-producer, one distinction is worth building into the outcome vocabulary from the start. The superset under discussion (`allow`/`deny`/`warn`/...) collapses two cases that an auditor reads differently:\n\n- **A control resolved an attempt.** The agent tried something and a policy denied it. There's a decision, and a terminal `deny`.\n- **Nothing was in the reachable surface.** There was no attempt, because there was nothing to attempt, so no decision happens at all.\n\nDownstream both read as \"didn't run\", but they aren't the same fact: one is \"a control fired\", the other is \"it was never on the table\". If the enum folds them together, that difference is lost.\n\nOne paired point on the telemetry:\n\n- A denied decision should still leave a trace. The deliberately-absent child execute span next to a terminal `deny` is what keeps the denial auditable after the fact.\n- If a blocked call emits nothing, \"denied\" and \"never attempted\" look identical downstream.\n\nBoth are structural properties of the decision point, separate from the measured signals (trust / drift) in this PR.\n\nOn ...[truncated]", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15723,20 +16502,21 @@ "requester": "chopmob-cloud", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-07-02T16:43:11Z", "body": "This is shaping up well, and making the authorization decision its own operation is the right call. Two thoughts on the `deny` span, since that is the load-bearing case.\n\n**1. The producer-scoped `.method` tokens are the correct default, and they also define the one thing a downstream auditor cannot do, which is recompute.** By design `trust.score` with `trust.method` lets an observer correlate a score against outcomes, but not re-derive the score or verify that a given span corresponds to a specific decision. For most telemetry that is exactly right. For the `deny` span you are making first-class (outcome plus reason plus policy, no child execute span beneath it), the property an auditor usually wants is not the score itself but \"is this recorded decision the one that actually gated the action, and can I check that offline without trusting the producer's number.\" That is a different need, and an opaque score cannot serve it.\n\n**2. An optional content-addressed decision reference closes that gap without making anything normative.** A single optional string attribute in `gen_ai.agent.*`, a hash over the canonical decision inputs (capability, policy version, outcome, the identity fro ...[truncated]", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ - "author_action", + "no_author_action", "author_action", "author_action", "author_action", @@ -15750,17 +16530,18 @@ "requester": "giskard09", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-07-02T17:48:03Z", "body": "That's the standalone proposal — draft-etcheverry-action-ref-01 (https://datatracker.ietf.org/doc/draft-etcheverry-action-ref/), single frozen JCS derivation profile, conformance vectors across independent implementers (argentum-core as reference implementation). Doesn't touch this operation's shape — separate primitive, separate surface, same distinction you're drawing here between trace structure and content-addressed identity.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15777,17 +16558,18 @@ "requester": "AgentGymLeader", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-07-02T17:49:59Z", "body": "@thebenignhacker Making it a structural invariant rather than an enum value is the right call. The absence of a child execute span is load-bearing in a way a producer can't fake by labeling, which is what makes it hold up for an auditor. The `execute_authorization` sketch reads clean too. Happy to help pressure-test the invariants as it lands.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15804,51 +16586,25 @@ "requester": "chopmob-cloud", "pr_author": "thebenignhacker", "review_state": null, + "root_timestamp": "2026-07-19T15:49:09Z", "body": "Thanks for the mention, and for taking the fail-closed algorithm point on board.\n\nOne related thing we shipped today: `jcs_edge_v1`, an open (Apache-2.0) RFC 8785 conformance set pinning the canonicalisation edge cases a naive serialiser gets wrong (U+2028 and U+2029 as literal UTF-8, property ordering by UTF-16 code units, `1.0` versus `1`), validated byte-for-byte across ten independent JCS implementations.\n\nhttps://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/tree/main/vectors/jcs_edge_v1", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" - ], - "run_labels": [ "no_author_action", "no_author_action", "no_author_action", "no_author_action", "no_author_action" - ] - }, - { - "id": "pr-review-4559593502", - "repo": "semantic-conventions-genai", - "pull_request": 291, - "requester": "lmolkova", - "pr_author": "thebenignhacker", - "review_state": "CHANGES_REQUESTED", - "body": "could you please add reference scenarios showing which instrumentation can capture these attributes, how they would do it, and which signals these attributes would appear on? Check out https://github.com/open-telemetry/semantic-conventions-genai/blob/main/CONTRIBUTING.md#4-update-reference-scenarios for the details", - "role": "scored", - "stability": "stable", - "recorded_label": "author_action", - "adjudicated_label": null, - "run_actions": [ - "author", - "author", - "author", - "author", - "author" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -15858,17 +16614,18 @@ "requester": "JWinermaSplunk", "pr_author": "AgentGymLeader", "review_state": "COMMENTED", + "root_timestamp": "2026-07-10T18:12:15Z", "body": "Can we go ahead and rebase and regenerate the `uv.lock`? Believe `opentelemetry-instrumentation==0.63b1` requires `opentelemetry-semantic-conventions==0.63b1` but we're currently on `opentelemetry-semantic-conventions==0.64b0`. Think we should consider upgrading `opentelemetry-instrumentation` or allow it to resolve a compatible version.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15885,17 +16642,18 @@ "requester": "JWinermaSplunk", "pr_author": "AgentGymLeader", "review_state": "APPROVED", + "root_timestamp": "2026-07-13T18:46:45Z", "body": "LGTM, can we go ahead and update the package version to `opentelemetry-util-genai==1.0b0` in the description and file a follow up issue(s) for Compaction in either this repo and/or the python genai repo based on any actionable findings here? Encryption via `encrypted_content` and support within the handler for `CompactionPart` are the two that came to mind, if not already present. Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15912,17 +16670,18 @@ "requester": "JWinermaSplunk", "pr_author": "lmolkova", "review_state": "APPROVED", + "root_timestamp": "2026-06-30T18:35:00Z", "body": "Small note, but I believe the Towncrier type in the changelog filename should enhancement? Otherwise, looks good!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -15939,24 +16698,25 @@ "requester": "lmolkova", "pr_author": "JacksonWeber", "review_state": "APPROVED", + "root_timestamp": "2026-07-10T00:24:01Z", "body": "LGTM, just a few cosmetic suggestions", "role": "scored", "stability": "stable", - "recorded_label": "author_action", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", - "author_action", - "author_action", - "author_action", - "author_action" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ] }, { @@ -15966,17 +16726,18 @@ "requester": "lmolkova", "pr_author": "JacksonWeber", "review_state": "APPROVED", + "root_timestamp": "2026-07-14T15:29:18Z", "body": "LGTM", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -15987,52 +16748,58 @@ ] }, { - "id": "pr-issue-comment-5079243760", + "id": "pr-review-4740229566", "repo": "semantic-conventions-genai", "pull_request": 359, - "requester": "mukundheda", + "requester": "lmolkova", "pr_author": "Mohnish-Srivats", - "review_state": null, - "body": "We built this pattern independently (an app-level tag, `augmentloop.grade.source`, on `gen_ai.evaluation.result`) and it maps onto your `evaluator.type` enum: our `math` (a deterministic checker compares against a provably-correct answer) is your `deterministic`; our `ai_judge` is your `llm_judge`. We never let `ai_judge` grades into anything that feeds a headline \"correct\" number, filtered by source rather than by convention.\n\nOne gap: our third source, `reality`, has no slot. It's a grade that arrives asynchronously, after the decision's span has closed, from an actual outcome rather than a check or an opinion: the clip was actually kept, the appointment actually landed. Not `deterministic` (nothing computes it at eval time), not `llm_judge` (no model ever scores it). We handle it by re-emitting the event with a span link back to the original decision span, plus the same `gen_ai.response.id` as correlation fallback, so a late verdict stays one hop from the decision it judges. Might be worth a fifth value, or a line in the spec noting that resolution timing is orthogonal to evaluator type: `reality` could pair with any of the current four.\n\nOn @lmolkova's capturability table: it m ...[truncated]", + "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-21T02:31:48Z", + "body": "I asked AI to do research on azure-ai-evals, deep-evals, dspy (the ones we're adding scenarios for) to check which of these attributes we could capture with generic instrumentations\n\n\n| Attribute | deepeval | dspy | azure-ai-evaluation |\n|---|---|---|---|\n| `evaluator.id` | **Constructed, not native.** Metric has `.name`; build id from name+model: `f\"{metric.__name__}-{metric.evaluation_model}\"` | **Constructed.** Metric is a callable → `metric.__name__` | **Constructed.** Evaluator is a class → `type(ev).__name__` + `model_config[\"model\"]` |\n| `evaluator.version` | **Not native** — no version concept. Scenario hardcodes `\"1.0\"` | **Not native.** Function has no version | **Not native** (not claimed in report). Would be hardcoded |\n| `evaluator.type` | **Inferable.** Native metrics use an LLM (`using_native_model`/`evaluation_model` set) → `llm_judge`; custom `BaseMetric` w/o model → `deterministic` | **Weak.** Metric is just a callable; DSPy can't tell if it calls an LLM. Scenario assumes `deterministic` | **Inferable from class:** AI-assisted (`RelevanceEvaluator`…) → `llm_judge`; NLP/math (`F1ScoreEvaluator`, `BleuScoreEvaluator`, `RougeScoreEvaluator`) → `deterministic` |\n| `r ...[truncated]", "role": "scored", - "stability": "stable", - "recorded_label": "author_action", + "stability": "flaky", + "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "no_author_action", + "no_author_action", + "author_action", + "no_author_action", + "author_action" ], "run_labels": [ + "no_author_action", + "no_author_action", "author_action", - "author_action", - "author_action", - "author_action", + "no_author_action", "author_action" ] }, { - "id": "pr-review-4740229566", + "id": "pr-issue-comment-5079243760", "repo": "semantic-conventions-genai", "pull_request": 359, - "requester": "lmolkova", + "requester": "mukundheda", "pr_author": "Mohnish-Srivats", - "review_state": "CHANGES_REQUESTED", - "body": "I asked AI to do research on azure-ai-evals, deep-evals, dspy (the ones we're adding scenarios for) to check which of these attributes we could capture with generic instrumentations\n\n\n| Attribute | deepeval | dspy | azure-ai-evaluation |\n|---|---|---|---|\n| `evaluator.id` | **Constructed, not native.** Metric has `.name`; build id from name+model: `f\"{metric.__name__}-{metric.evaluation_model}\"` | **Constructed.** Metric is a callable → `metric.__name__` | **Constructed.** Evaluator is a class → `type(ev).__name__` + `model_config[\"model\"]` |\n| `evaluator.version` | **Not native** — no version concept. Scenario hardcodes `\"1.0\"` | **Not native.** Function has no version | **Not native** (not claimed in report). Would be hardcoded |\n| `evaluator.type` | **Inferable.** Native metrics use an LLM (`using_native_model`/`evaluation_model` set) → `llm_judge`; custom `BaseMetric` w/o model → `deterministic` | **Weak.** Metric is just a callable; DSPy can't tell if it calls an LLM. Scenario assumes `deterministic` | **Inferable from class:** AI-assisted (`RelevanceEvaluator`…) → `llm_judge`; NLP/math (`F1ScoreEvaluator`, `BleuScoreEvaluator`, `RougeScoreEvaluator`) → `deterministic` |\n| `r ...[truncated]", - "role": "context", - "stability": null, - "recorded_label": null, + "review_state": null, + "root_timestamp": "2026-07-25T16:23:06Z", + "body": "We built this pattern independently (an app-level tag, `augmentloop.grade.source`, on `gen_ai.evaluation.result`) and it maps onto your `evaluator.type` enum: our `math` (a deterministic checker compares against a provably-correct answer) is your `deterministic`; our `ai_judge` is your `llm_judge`. We never let `ai_judge` grades into anything that feeds a headline \"correct\" number, filtered by source rather than by convention.\n\nOne gap: our third source, `reality`, has no slot. It's a grade that arrives asynchronously, after the decision's span has closed, from an actual outcome rather than a check or an opinion: the clip was actually kept, the appointment actually landed. Not `deterministic` (nothing computes it at eval time), not `llm_judge` (no model ever scores it). We handle it by re-emitting the event with a span link back to the original decision span, plus the same `gen_ai.response.id` as correlation fallback, so a late verdict stays one hop from the decision it judges. Might be worth a fifth value, or a line in the spec noting that resolution timing is orthogonal to evaluator type: `reality` could pair with any of the current four.\n\nOn @lmolkova's capturability table: it m ...[truncated]", + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - null, - null, - null, - null, - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ + "author_action", + "author_action", + "author_action", + "author_action", "author_action" ] }, @@ -16043,22 +16810,24 @@ "requester": "2505552499", "pr_author": "grvnmttl", "review_state": null, + "root_timestamp": "2026-07-26T18:09:10Z", "body": "`INFORMED_BY` captures provenance between a tool result and a later generation.\nI measured a related quantity that current usage attributes cannot expose: how\nmuch of each model input is new versus logical replay from the preceding\nconversation context.\n\nI recorded two real coding-agent sessions and verified prompt continuity with\nblock-level prefix hashes; the quantity is the exact token LCP between adjacent\nprompts, computed while token IDs were in memory and stored as one integer. No\nraw text is retained. Counts here come from a local `cl100k_base` tokenizer\nrather than provider-reported usage, which matters for units — see below.\n\n| session | steps | total prompt tokens | logical replay |\n|---|---:|---:|---:|\n| A | 17 | 170,714 | 147,902 (87%) |\n| B | 27 | 400,211 | 368,620 (92%) |\n\nIn session B, one source step added 2,841 tokens to the next prompt. Those\ntokens appeared in 19 later prompts, totalling 53,979 replayed tokens (19x).\n\n`gen_ai.usage.input_tokens` records total input, while\n`gen_ai.usage.cache_read.input_tokens` records provider-cache delivery. Neither\nanswers whether input is new or already present in the logical agent context.\nCould a companion split on `chat` sp ...[truncated]", - "role": "context", - "stability": null, - "recorded_label": null, + "role": "scored", + "stability": "stable", + "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - null, - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", "author_action", "author_action", + "author_action", "author_action" ] }, @@ -16069,22 +16838,23 @@ "requester": "mx-psi", "pr_author": "trask", "review_state": "APPROVED", + "root_timestamp": "2026-07-22T09:38:14Z", "body": "The TC has write permissions on every repo, so their approval would be counted as someone with write access but the ruleset may not allow maintainers to merge the PR. It's a small edge case, but maybe it could be confusing?\n\nOtherwise looks good to me, if you think that this is not worth worrying about feel free to merge :)", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "author", - "none", - "author", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ - "author_action", "no_author_action", - "author_action", + "no_author_action", + "no_author_action", "no_author_action", "no_author_action" ] @@ -16096,17 +16866,18 @@ "requester": "jerbly", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-07-13T12:08:24Z", "body": "Had a quick look. This appears to be a freeform yaml block. Could `annotations` be used instead? We recently backed-out of spec change for `value_type` in favour of `annotations`. This feels the same to me.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16123,17 +16894,18 @@ "requester": "jsuereth", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-07-14T22:32:45Z", "body": "I don't think we make any requirement on delta vs. cumulative, but we should have a way to specify histogram boundaries.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16150,17 +16922,18 @@ "requester": "jsuereth", "pr_author": "thompson-tomo", "review_state": null, + "root_timestamp": "2025-08-18T12:12:12Z", "body": "Are packages versioned? What's the difference between a package and just a repository directly?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16177,17 +16950,18 @@ "requester": "lquerel", "pr_author": "ArthurSens", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-01-07T18:12:20Z", "body": "We should change the tests to validate with the real archive URLs.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16204,17 +16978,18 @@ "requester": "jsuereth", "pr_author": "lmolkova", "review_state": "APPROVED", + "root_timestamp": "2026-07-16T21:33:24Z", "body": "@lmolkova FYI - I forgot to approve this oh so long ago - Approving now if we still consider this a blocker - hopefully it's easy to bring this back up to date and merge if we want it.", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -16231,17 +17006,18 @@ "requester": "jsuereth", "pr_author": "ANcpLua", "review_state": null, + "root_timestamp": "2026-07-23T12:25:17Z", "body": "Generally fix looks good - would approve, but I think Co-pilot found the bug in the windows build. Please fix tests and then I think we can merge.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16258,17 +17034,18 @@ "requester": "jsuereth", "pr_author": "McGluut", "review_state": "APPROVED", + "root_timestamp": "2026-07-23T18:31:22Z", "body": "Overall - this looks like a nice addition, thanks for contributing!", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -16285,17 +17062,18 @@ "requester": "lmolkova", "pr_author": "McGluut", "review_state": "APPROVED", + "root_timestamp": "2026-07-24T16:16:35Z", "body": "@McGluut thanks for the contribution!\n\nI'd like to start release sometime soon and would love to get this change in - it'd be really useful in some tests we have in otel. \n\nIf you're around, could you please take a look at the open discussion. Otherwise I might just auto-apply the suggestion I left and merge the PR in a hope you won't mind it. Thanks!", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16312,17 +17090,18 @@ "requester": "jerbly", "pr_author": "McGluut", "review_state": "CHANGES_REQUESTED", + "root_timestamp": "2026-07-24T17:15:51Z", "body": "Thank you - I think this is pretty close and useful. I would like it to be aligned with how we handle `resource` though. And in solving how to pass the `instrumentation_scope` to rego we can do the same for `resource`.", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16339,17 +17118,18 @@ "requester": "jerbly", "pr_author": "McGluut", "review_state": "COMMENTED", + "root_timestamp": "2026-07-25T21:43:14Z", "body": "We're very close. This is really good. Let's remove that Template section and make sure to update the docs: https://github.com/open-telemetry/weaver/tree/main/crates/weaver_live_check#custom-advisors", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16366,17 +17146,18 @@ "requester": "jsuereth", "pr_author": "jerbly", "review_state": null, + "root_timestamp": "2026-07-27T19:53:54Z", "body": "> Middle's re-export is stamped with middle's schema_url instead of base's, so resolution fails with\r\n\r\nThis is a bug - I assume this happened from a previous release before we had better multi-dependency resolution?", "role": "scored", "stability": "stable", "recorded_label": "author_action", "adjudicated_label": null, "run_actions": [ - "author", - "author", - "author", - "author", - "author" + "author_action", + "author_action", + "author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", @@ -16393,24 +17174,25 @@ "requester": "jsuereth", "pr_author": "jerbly", "review_state": null, + "root_timestamp": "2026-07-27T20:05:14Z", "body": "100% agree 2 + 3 are our bugs that must be fixed.\r\n\r\nFor 1 - it's an interesting, temporary, problem. Fixing the `include_unrefereenced` flag to remember provenance *should* fix this issue once published repositories upstream are fixed. If we have a fix - I think it should be a temporary issue.", "role": "scored", "stability": "flaky", "recorded_label": null, "adjudicated_label": null, "run_actions": [ - "author", - "none", - "none", - "author", - "none" + "author_action", + "author_action", + "no_author_action", + "author_action", + "author_action" ], "run_labels": [ "author_action", - "no_author_action", + "author_action", "no_author_action", "author_action", - "no_author_action" + "author_action" ] }, { @@ -16420,22 +17202,23 @@ "requester": "jsuereth", "pr_author": "jerbly", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T15:55:10Z", "body": "Fix looks good, thanks for catching this bug. Looks like an opportunity to refacor/clean up the logic after a point fix release!", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "author", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", - "author_action", + "no_author_action", "no_author_action", "no_author_action" ] @@ -16447,23 +17230,24 @@ "requester": "jsuereth", "pr_author": "jerbly", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T15:59:38Z", "body": "Fix is good but lots of duplicated code or repeated logic.\n\nGiven urgency of the bugs we can clean this up post submission.\n\nThis is also one of those \"duh\" moments - we know attributes can change across version and treating the whole group as a version is a good thing", "role": "scored", - "stability": "flaky", - "recorded_label": null, + "stability": "stable", + "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "author", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", "no_author_action", "no_author_action", - "author_action", + "no_author_action", "no_author_action" ] }, @@ -16474,17 +17258,18 @@ "requester": "jsuereth", "pr_author": "jerbly", "review_state": "APPROVED", + "root_timestamp": "2026-07-28T16:02:20Z", "body": "Another thing we should have fixed! Good catch", "role": "scored", "stability": "stable", "recorded_label": "no_author_action", "adjudicated_label": null, "run_actions": [ - "none", - "none", - "none", - "none", - "none" + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action", + "no_author_action" ], "run_labels": [ "no_author_action", @@ -16495,4 +17280,4 @@ ] } ] -} \ No newline at end of file +} diff --git a/.github/scripts/pull-request-dashboard/test_eval_baseline.py b/.github/scripts/pull-request-dashboard/test_eval_baseline.py new file mode 100644 index 00000000000..81c19a4ab3f --- /dev/null +++ b/.github/scripts/pull-request-dashboard/test_eval_baseline.py @@ -0,0 +1,200 @@ +import json +import sys +import tempfile +import unittest +from pathlib import Path +from unittest.mock import patch + +sys.path.insert(0, str(Path(__file__).resolve().parent / "eval")) + +import regenerate_baseline # noqa: E402 +from regenerate_baseline import answers, rebuild, run_batch # noqa: E402 + + +def case(case_id: str, *, adjudicated_label=None) -> dict: + return { + "id": case_id, + "repo": "repo", + "pull_request": 1, + "requester": "reviewer", + "pr_author": "author", + "review_state": None, + "root_timestamp": "2026-01-01T00:00:00Z", + "body": "body", + "role": "scored", + "stability": "stable", + "recorded_label": "no_author_action", + "adjudicated_label": adjudicated_label, + "run_actions": [], + "run_labels": [], + } + + +def payload(*cases: dict) -> dict: + return { + "baseline_configuration": {"model": "old", "prompt": "old", "runs": 1}, + "counts": {}, + "cases": list(cases), + } + + +def response(*items: dict) -> dict: + return {"returncode": 0, "stdout": json.dumps({"items": list(items)})} + + +class AnswersTest(unittest.TestCase): + def test_verdicts_are_keyed_by_case_id(self) -> None: + raw = response({"discussion_id": "a", "verdict": "author_action"}) + + self.assertEqual({"a": "author_action"}, answers(raw, [case("a")])) + + def test_a_failed_call_answers_nothing(self) -> None: + raw = {"returncode": 1, "stdout": json.dumps({"items": [{"discussion_id": "a"}]})} + + self.assertEqual({}, answers(raw, [case("a")])) + + def test_an_unparseable_response_answers_nothing(self) -> None: + self.assertEqual({}, answers({"returncode": 0, "stdout": "sorry"}, [case("a")])) + + def test_a_response_without_items_answers_nothing(self) -> None: + raw = {"returncode": 0, "stdout": json.dumps({"verdict": "author_action"})} + + self.assertEqual({}, answers(raw, [case("a")])) + + def test_an_id_that_was_not_asked_for_is_ignored(self) -> None: + raw = response( + {"discussion_id": "a", "verdict": "author_action"}, + {"discussion_id": "invented", "verdict": "author_action"}, + ) + + self.assertEqual({"a": "author_action"}, answers(raw, [case("a")])) + + def test_an_unknown_verdict_is_not_an_answer(self) -> None: + raw = response({"discussion_id": "a", "verdict": "maybe"}) + + self.assertEqual({}, answers(raw, [case("a")])) + + def test_a_duplicated_id_drops_the_answer_it_already_had(self) -> None: + raw = response( + {"discussion_id": "a", "verdict": "author_action"}, + {"discussion_id": "a", "verdict": "no_author_action"}, + {"discussion_id": "b", "verdict": "no_author_action"}, + ) + + # Production fails a discussion whose id comes back twice rather than + # picking one, so neither answer can be trusted here either. + self.assertEqual({"b": "no_author_action"}, answers(raw, [case("a"), case("b")])) + + +class RebuildTest(unittest.TestCase): + def test_runs_that_agree_are_stable(self) -> None: + rebuilt = rebuild(payload(case("a")), [{"a": "author_action"}] * 3, "model") + + self.assertEqual("scored", rebuilt["cases"][0]["role"]) + self.assertEqual("stable", rebuilt["cases"][0]["stability"]) + self.assertEqual("author_action", rebuilt["cases"][0]["recorded_label"]) + + def test_runs_that_disagree_are_flaky_without_a_recorded_label(self) -> None: + trials = [{"a": "author_action"}, {"a": "no_author_action"}] + rebuilt = rebuild(payload(case("a")), trials, "model") + + self.assertEqual("scored", rebuilt["cases"][0]["role"]) + self.assertEqual("flaky", rebuilt["cases"][0]["stability"]) + self.assertIsNone(rebuilt["cases"][0]["recorded_label"]) + + def test_one_unanswered_run_leaves_a_case_as_context(self) -> None: + trials = [{"a": "author_action"}, {}, {"a": "author_action"}] + rebuilt = rebuild(payload(case("a")), trials, "model") + + # Agreement among the runs that answered is not evidence the classifier + # is stable on a case it sometimes drops. + self.assertEqual("context", rebuilt["cases"][0]["role"]) + self.assertIsNone(rebuilt["cases"][0]["stability"]) + self.assertIsNone(rebuilt["cases"][0]["recorded_label"]) + self.assertEqual([None], rebuilt["cases"][0]["run_actions"][1:2]) + + def test_a_human_decision_survives_a_disagreeing_measurement(self) -> None: + cases = payload(case("a", adjudicated_label="no_author_action")) + rebuilt = rebuild(cases, [{"a": "author_action"}] * 3, "model") + + self.assertEqual("no_author_action", rebuilt["cases"][0]["adjudicated_label"]) + self.assertEqual("author_action", rebuilt["cases"][0]["recorded_label"]) + + def test_counts_and_configuration_describe_the_new_measurement(self) -> None: + cases = payload( + case("a", adjudicated_label="no_author_action"), + case("b"), + case("c"), + ) + trials = [ + {"a": "author_action", "b": "author_action", "c": "author_action"}, + {"a": "author_action", "b": "no_author_action"}, + ] + rebuilt = rebuild(cases, trials, "measured-model") + + self.assertEqual( + { + "cases": 3, + "scored": 2, + "context": 1, + "stable": 1, + "flaky": 1, + "adjudicated": 1, + }, + rebuilt["counts"], + ) + self.assertEqual("measured-model", rebuilt["baseline_configuration"]["model"]) + self.assertEqual(2, rebuilt["baseline_configuration"]["runs"]) + self.assertEqual( + regenerate_baseline.PROMPT, rebuilt["baseline_configuration"]["prompt"] + ) + + +class RunBatchCachingTest(unittest.TestCase): + def setUp(self) -> None: + cache = tempfile.TemporaryDirectory() + self.addCleanup(cache.cleanup) + self.cache = Path(cache.name) + patcher = patch.object(regenerate_baseline, "CACHE_DIR", self.cache) + patcher.start() + self.addCleanup(patcher.stop) + + def entries(self) -> list[Path]: + return list(self.cache.iterdir()) + + def run_with(self, proc) -> dict: + with patch.object(regenerate_baseline.classification, "run_copilot", proc): + return run_batch([case("a")], "model", "salt") + + def test_a_successful_call_is_cached(self) -> None: + raw = self.run_with(lambda prompt, model: _Completed(0, "{}")) + + self.assertEqual(0, raw["returncode"]) + self.assertEqual(1, len(self.entries())) + + def test_a_failed_call_is_not_cached(self) -> None: + # Caching a failure would make every later run replay it instead of + # retrying the call. + raw = self.run_with(lambda prompt, model: _Completed(1, "")) + + self.assertEqual(1, raw["returncode"]) + self.assertEqual([], self.entries()) + + def test_a_raising_call_is_not_cached(self) -> None: + def explode(prompt: str, model: str): + raise RuntimeError("throttled") + + raw = self.run_with(explode) + + self.assertIn("throttled", raw["error"]) + self.assertEqual([], self.entries()) + + +class _Completed: + def __init__(self, returncode: int, stdout: str) -> None: + self.returncode = returncode + self.stdout = stdout + + +if __name__ == "__main__": + unittest.main() diff --git a/.github/scripts/pull-request-dashboard/test_eval_fixture.py b/.github/scripts/pull-request-dashboard/test_eval_fixture.py index 1e2f505ca6b..ff5d953e988 100644 --- a/.github/scripts/pull-request-dashboard/test_eval_fixture.py +++ b/.github/scripts/pull-request-dashboard/test_eval_fixture.py @@ -1,8 +1,11 @@ import json import re import unittest +from itertools import groupby from pathlib import Path +from utils import truncate + CASES = Path(__file__).resolve().parent / "eval" / "reviewer_feedback_cases.json" LABELS = {"author_action", "no_author_action"} ROLES = {"scored", "context"} @@ -46,6 +49,25 @@ def test_every_case_has_a_traceable_body(self) -> None: self.assertTrue(case["repo"]) self.assertIsInstance(case["pull_request"], int) + def test_bodies_are_what_production_sends(self) -> None: + # derive_top_level_items truncates before classifying, so a body recorded + # verbatim would be scored against input the dashboard never sends. + for case in self.cases: + with self.subTest(case=case["id"]): + self.assertEqual(truncate(case["body"]), case["body"]) + + def test_cases_are_in_the_order_production_sends_them(self) -> None: + # Batch boundaries follow this order, so a case out of place would be + # measured in a batch the dashboard never assembles. + seen: set[tuple[str, int]] = set() + for group, cases in groupby(self.cases, key=lambda c: (c["repo"], c["pull_request"])): + with self.subTest(pull_request=group): + self.assertNotIn(group, seen) + seen.add(group) + stamps = [case["root_timestamp"] for case in cases] + self.assertTrue(all(stamps)) + self.assertEqual(sorted(stamps), stamps) + def test_every_field_the_scorer_reads_is_present(self) -> None: for case in self.cases: with self.subTest(case=case["id"]):