CI Test Results

Run: #43229730678 | Commit: 3a40805 | Duration: 20m 3s (longest job)

✅ All 32 test jobs passed

Status Overview

Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled

Summary: Total: 32 | Passed: 32 | Failed: 0

Updated: 2026-11-12 14:04:57 UTC

Scan-Build Report

Bug Summary

Filter Results by File

Reports

✅ All 40 integration tests passed

📊 Dashboard · 👷 Pipeline · 📦 9a30bde5

Agentic review of head b45dc07d8 against merge base fb82a0012 (main).

The range changes .claude/hooks/require-fresh-review.py and .githooks/pre-push, so the reviewer table's gate row applies. This review ran /code-review at high effort in a fresh context, reading code only at the head commit. I checked each finding below against the code.

What holds

• stale_description runs only after the marker check passes, so the new check can only add a block. Its fail-open paths reach only the new check.
• gh pr create and the pre-push block condition are unchanged.
• The timestamps are timezone-aware, and committer date is the right field for a rebase.
• The JvmtiEventTimingTest.java change is formatting only.

High: the staleness check almost never fires (require-fresh-review.py, stale_description)

• It compares the PR's updatedAt with the head commit's committedDate.
• GitHub bumps updatedAt on every push, CI status change, review, bot comment and label change, so it is nearly always later than the head commit.
• Example, Fix reference-chain nightly flakes and drop their quarantine #899: the body was last edited on 2026-10-25 (GraphQL lastEditedAt) and the head commit is from 2026-11-11. The hook's own probe returns updatedAt 2026-11-11T17:27:46Z and committedDate 2026-11-11T14:11:06Z, so it counts the PR as fresh and allows gh pr ready.
• The README's "blocks" and "a rebase blocks until the description is re-saved" do not happen in practice: the rebase push itself bumps updatedAt.
• The tests inject made-up timestamps, so they cannot catch this.
• Possible fix: query lastEditedAt through gh api graphql (gh pr view has no such field), and fall back to createdAt when it is null.
• A weaker gap remains even with that fix: committedDate is when the commit was made, not when it was pushed.

Low

• gh pr ready now makes two gh pr view calls on the same PR (ready_target and stale_description), each with a 10 s timeout. One query could serve both.
• pre-push now makes one gh call per pushed branch ref, not one per push. Offline, git push origin a b c can wait up to 10 s per ref.
• The pre-push warning prints for a passing ref even when another ref in the same push is blocked and nothing is pushed.
• utils/README.md: "a fresh marker still skips the marker check itself" contradicts the code, because review-marker.py check always runs.
• test_review_marker.sh: the gh stub returns the same updatedAt for any query, so a regression that queries the wrong PR (no selector or -R) would still pass.

This is a comment only, not an approval or a change request.

Addressed in the current head:

• High (updatedAt) — fixed in fbb9c52: the probe reads the body's own edit time (GraphQL lastEditedAt, createdAt fallback) instead of updatedAt.
• committedDate gap — real; documented as an accepted limit in utils/README.md (8fd44f6): the committer timestamp is backdatable, and an older commit force-pushed as head passes the gate.
• README "fresh marker skips the marker check" contradiction — fixed in 5bdded4: the sentence now states the actual behavior (the check always runs; a fresh marker only avoids the block).
• gh stub fidelity — fixed in e89f855: the graphql stub now answers only the queried owner/name, and the pr view stub honors URL selectors, so a regression querying the wrong repository or selector fails the suite.

Deferred, with reasons: the two pr view/graphql calls on the PR-ready path (each ≤10s and on a fail-open path — sharing one query complicates ready_target for little gain); the per-ref pre-push gh call (documented known limit); the pre-push warning printed for a passing ref when another ref in the same push is blocked (informational only).

Two additional bot findings were fixed in this round: the graphql jq argument's implicit string concatenation (c5e344d) and the description probe querying the -R repository instead of the PR URL's (e89f855, pinned by the new stub).

Agentic re-review of head 9edb83098 against merge base 399ce5e60 (main). The branch was rebuilt since my review of b45dc07d8, so this covers the whole PR again. Reviewer: /code-review at high effort in a fresh context, reading code only at the head commit (gate row; the PR changes require-fresh-review.py and .githooks/pre-push). I checked each finding below against the code.

Earlier findings

• The High is fixed: the check now dates the description by lastEditedAt, with createdAt when the body was never edited, not by updatedAt. Bot body edits (the Jira bot) come about 5 s after a human edit, so they do not defeat it.
• The README sentence about the marker check now matches the code.

What holds

• The staleness probe runs only after the marker check passes, so it can only add a block. Every fail-open path affects only the new check.
• The pre-push block condition is unchanged.

Medium: the description probe can read a different repository than gh pr ready uses (evaluate, pr_repo)

• ready_target gets the PR from gh's own resolution, but the probe resolves the repository again: a PR_URL match (https://github.com/ only), then the -R value, then gh repo view.
• With an http://, GHES or upper-case-host URL and a different -R, the probe reads the dates of an unrelated PR, so it can block or pass on the wrong PR.
• gh repo view has no -R flag (gh 2.91.0: "unknown shorthand flag: 'R' in -R"). So for an -R value that is not OWNER/NAME, for example github.com/DataDog/java-profiler, pr_repo always fails and the check silently fails open.
• Possible fix: return the PR's id or url from the same gh pr view call in ready_target, and query node(id:). That removes pr_repo and the second selector parse.

Low

• The head commit is dated through a separate commits(last:1) read, not the headRefOid that the marker check approved. A push between the two calls compares against a different commit. repository.object(oid:) would bind it.
• A commit with a future-dated committer clock blocks gh pr ready until wall-clock time catches up, and no description edit can clear it.
• It is unconfirmed that re-saving an identical body moves lastEditedAt, which the README's "a no-op edit clears it" relies on. A title-only edit does not move it.
• The "lacks a UTC designator" test uses a naive time later than the head, so it also passes if naive values were treated as UTC. A naive time earlier than the head would prove fail-open.
• The gh stub returns $VIEW_GRAPHQL as is, so the jq expression in stale_description never runs in the tests. Its repo view branch ignores -R, which is why the Medium is not caught. The stub's header comment does not list the new variables.
• has_open_pr now runs for every pushed branch ref. A ref whose remote sha is all zeros (a new branch) cannot have an open PR and could skip the call.
• The pre-push "re-verify its title and description" warning prints even when another ref in the same push is blocked and nothing is pushed.
• The stale_description docstring is 7 lines and describes a .[-1] approach that the code no longer uses, and the README uses history wording ("no longer skips the network"). Both are against the AGENTS.md comment and doc rules.

This is a comment only, not an approval or a change request.

Addressed in the current head:

• Medium (probe reads a different repository) — fixed in bc97dab: ready_target now returns the PR's node id from the same gh pr view call, and the probe queries node(id:) with it. pr_repo and the second URL/-R parse are gone, so the http/GHES/upper-case-host and non-OWNER/NAME -R cases cannot disagree with what gh pr ready targets.
• Low (head commit from a separate read) — fixed in bc97dab: the same query returns the PR's own headRefOid, which must match the marker-approved oid or the gate fails open; the commit date and the description timestamps now come from one response.
• Low (future-dated committer clock) — fixed in bc97dab: a committer date more than five minutes ahead of the wall clock fails open.
• Low (naive-time test direction) — fixed in bc97dab: the naive timestamp is now earlier than the head, so the test fails if naive values were treated as UTC.
• Low (stub fidelity) — fixed in bc97dab: the stub applies the command's real --jq expression and keys the graphql answer on the queried node id; the header comment lists the new variables. The jq path in stale_description is now exercised.
• Low (all-zero remote sha) — fixed in bc97dab: pre-push skips the open-PR probe for refs the push creates.
• Low (warning with a blocked ref) — fixed in bc97dab: the description warning is deferred and prints only when the push is not blocked.
• Low (docstring/README wording) — fixed in bc97dab: the stale_description docstring describes the current mechanism, and the README sentences are in current-state wording.

Deferred, with reasons: the two pr view/graphql calls on the PR-ready path (both on fail-open paths, each ≤10s; sharing one query complicates ready_target for little gain); a test pinning the exact COMMIT_DATE_SKEW boundary (would race the hook's clock and flake; the boundary behavior on either side is immaterial).

One follow-up review finding was also fixed: the no-commits test's fixture left $WT_TIP unexpanded, so it passed through the oid-mismatch guard instead of the empty-commits path (9a30bde).

Reliability & Chaos Results

✅ All reliability & chaos checks passed Pipeline: https://gitlab.ddbuild.io/DataDog/java-profiler/-/pipelines/152550713

/merge

View all feedbacks in Devflow UI.

2026-11-12 13:10:47 UTC ℹ️ Start processing command /merge

2026-11-12 13:10:52 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 53m (p90).

2026-11-12 13:41:41 UTC ℹ️ MergeQueue: This merge request was merged