Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* Collapse completed author reminders

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f7e532a5-ed16-440b-9de4-ad18e5f20c51

* Address Copilot review comment: preserve CAS retry completions

Copilot comment:

On a CAS retry, this drops an already-posted reminder when a concurrent refresh has removed the baseline entry after the PR left the author route: `baseline_waiting_since` is empty, so the retry snapshot is ignored even though its GitHub comment was already created. With no accepted nudge entry left, no completion is queued and that reminder remains active indefinitely. Reconcile this case by retaining the retry episode as a pending completion without overwriting any newer baseline episode.

Analysis: A successful comment post can be captured only in the retry snapshot while the accepted baseline concurrently advances to a different or absent author episode. Merge the posted retry episode into the baseline as a routing-changed completion, preserving all current baseline fields and deduplicating by episode ID.

Upsides: Every posted reminder is eventually collapsed, and newer accepted author episodes remain authoritative across CAS retries.

Downsides: The completion timestamp uses the reminder post time because the exact concurrent routing-change time is unavailable.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: e40eb183-885e-4b33-b29c-a50f4f1d74f9

* Address Copilot review comment: enforce Outdated classifier

Copilot comment:

`isMinimized` does not identify the classifier. If this reminder was already minimized as SPAM, ABUSE, or another reason, this branch skips the mutation and never applies the required **Outdated** classification. Query the minimization reason and skip only when it is already `OUTDATED`; otherwise explicitly reclassify it.

Analysis: A minimized comment can carry a classifier other than Outdated. Query and normalize the minimization reason, leave comments already classified Outdated unchanged, and unminimize then minimize comments carrying another classifier so GitHub applies Outdated deterministically.

Upsides: Completed reminders consistently use the documented Outdated classification while preserving idempotency for comments already classified correctly.

Downsides: Reclassification requires one additional GraphQL mutation for comments minimized under another classifier.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: e40eb183-885e-4b33-b29c-a50f4f1d74f9

* Address Copilot review comments: harden legacy recovery

Copilot comment:

An exhaustive lookup that finds no legacy comment is terminal—for example, the author may have deleted the reminder—and the desired state already has no stale comment to collapse. Keeping this completion and returning an error makes every future hourly delivery fail forever; API failures already raise and are retried without saving state. Log the missing comment and discard this completion instead of re-queuing it.

Copilot comment:

`nudged_at` in legacy v2 state was recorded from the delivery run's shared `now`, not from the comment API's actual `created_at` (see `ensure_nudge` line 445). A delivery that reaches this PR more than ten minutes after starting therefore cannot recover an existing reminder and leaves it uncollapsed. Since a second reminder cannot be posted until a new week-long episode, a wider sub-week window (for example, one day) remains unambiguous while covering long runs.
```
LEGACY_NUDGE_RECOVERY_WINDOW = timedelta(minutes=10)
```

Analysis: Legacy timestamps represent the delivery run start rather than exact comment creation. Expand recovery to one day, which remains below the one-week reminder interval, and treat an exhaustive no-match as terminal while allowing API failures to continue propagating for retry.

Upsides: Long delivery runs can recover existing reminders, while deleted or otherwise absent comments no longer poison every hourly delivery.

Downsides: Legacy matching accepts a wider timestamp range, though the one-reminder-per-week invariant keeps candidates unambiguous.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: e40eb183-885e-4b33-b29c-a50f4f1d74f9

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f7e532a5-ed16-440b-9de4-ad18e5f20c51
Copilot-Session: e40eb183-885e-4b33-b29c-a50f4f1d74f9

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* Add PR dashboard promotion workflow

Keep the stable rollout pins out of Renovate updates and provide a guarded workflow that opens a deliberate promotion pull request after canary validation.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 562cb0b5-80fe-48e5-9dc5-13348edaf303

* Use split tokens for promotion PRs

Match the Java instrumentation automation: push the branch with GITHUB_TOKEN and use OTELBOT only to open the pull request and request review.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 562cb0b5-80fe-48e5-9dc5-13348edaf303

* Address Copilot review comment: run dashboard tests from script directory

Copilot comment:

This discovery runs from the repository root, where `.github/scripts/pull-request-dashboard` is not an importable package, so `unittest discover` completes successfully with zero dashboard tests. The generated workflow therefore bypasses `test_rollout.py`, the guard intended to validate the modified pins. Run discovery from the script directory, as the existing dashboard test workflow does.

Analysis: The promotion workflow invoked unittest discovery from the repository root, unlike the existing dashboard test workflow. Setting the step working directory to the dashboard script directory makes discovery import and execute the full dashboard test suite, including the rollout pin guards.

Upsides: Promotion PRs cannot be created unless the modified rollout pins pass the same 460 Python tests used by the dashboard test workflow.

Downsides: The promotion workflow spends additional time running the intended test suite; no material functional downside identified.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: restrict promotion PR reuse

Copilot comment:

The idempotency lookup trusts only the PR title, so any contributor can open a PR with this predictable title and cause the workflow to skip creating the validated OTELBOT branch, request Copilot on the unrelated PR, and report it as the promotion. Restrict reuse to a PR authored by this GitHub App and using the expected branch namespace/base.

Analysis: The existing lookup selected the first open PR with a predictable title. The revised lookup reuses only same-repository PRs authored by `otelbot[bot]`, targeting `main`, and using the exact release-specific OTELBOT branch prefix generated by this workflow.

Upsides: Contributor-authored or cross-repository PRs can no longer divert the promotion flow, receive an unintended Copilot request, or be reported as the validated promotion. Reusing the branch prefix variable also keeps creation and lookup criteria aligned.

Downsides: If the GitHub App login or branch convention changes, an existing promotion PR will not be reused until this workflow is updated.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: make rerun branches unique

Copilot comment:

A job rerun keeps the same `GITHUB_RUN_ID`. If the first attempt pushes this branch but fails before `gh pr create` completes, the rerun finds no PR, recreates a different commit under the same branch name, and the non-fast-forward push fails. Include `GITHUB_RUN_ATTEMPT` so a rerun can recover from this partial-failure window.
```
            branch="${branch_prefix}${GITHUB_RUN_ID}"
```

Analysis: A workflow rerun shares its run ID with the original attempt, so the previous branch name could collide with a branch pushed before a failed PR creation. Appending `GITHUB_RUN_ATTEMPT` gives each attempt a distinct branch while retaining the release-specific prefix used by safe PR discovery.

Upsides: Reruns recover cleanly from failures between branch push and PR creation instead of failing on a non-fast-forward push.

Downsides: Failed attempts can leave additional unreferenced promotion branches for normal repository cleanup.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Remove promotion PR lookup

Always create a uniquely named OTELBOT promotion branch and pull request. Operators can close a duplicate manually if a rare retry occurs after PR creation.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 673d5bdc-1137-477d-8ab3-54666f695f22

* Open promotion PRs ready for review

Open generated promotion pull requests ready for review and rely on the repository's automatic Copilot review instead of requesting it explicitly.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 673d5bdc-1137-477d-8ab3-54666f695f22

* Address Copilot review comment: prevent duplicate promotions

Copilot comment:

Every dispatch creates a run-specific branch without checking for an existing promotion PR. A retry or second operator dispatch for the same release therefore opens duplicate rollout PRs; the concurrency group only serializes runs. Before creating a branch, reuse or fail on an existing OTELBOT-authored PR for the same release, base, and expected branch namespace.
```
          title="Promote pull request dashboard to $RELEASE"
          branch="otelbot/promote-pull-request-dashboard-${RELEASE#v}-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}"
          git config user.name otelbot
          git config user.email 197425009+otelbot@users.noreply.github.com
          git checkout -b "$branch"
```

Analysis: Run-specific branches prevent branch collisions but do not prevent duplicate pull requests across retries or separate dispatches. The workflow now searches open pull requests for the exact release title and reuses only same-repository PRs authored by `otelbot[bot]`, targeting `main`, and using the release-specific OTELBOT branch namespace.

Upsides: Repeated dispatches remain idempotent without allowing contributor-authored, cross-repository, wrong-base, or unrelated OTELBOT pull requests to divert the promotion flow.

Downsides: A change to the OTELBOT login or promotion branch convention requires the lookup criteria to be updated.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: request promotion review

Copilot comment:

The workflow only opens the PR; it never requests a Copilot review. The dashboard configuration for `shared-workflows` also does not enable the clean-Copilot-review gate (`repositories.json:72-73`), so this does not deliver the automatic review promised by the PR description. Grant the appropriate `copilot-requests` permission and explicitly request Copilot after creating the PR (or configure an equivalent guaranteed mechanism).
```
          pr_url=$(gh pr create \
            --title "$title" \
            --body "$body" \
            --base main \
            --head "$branch")
```

Analysis: The promotion workflow relied on repository-level automatic review despite not configuring the dashboard's clean-review gate. The job now grants `copilot-requests: write` to its Actions token and uses that token explicitly to request Copilot after creating or recovering the promotion pull request, while retaining the OTELBOT installation token for pull request creation.

Upsides: Every generated or recovered promotion pull request receives a deterministic Copilot review request, independent of dashboard configuration and without broadening the OTELBOT app token's permissions.

Downsides: Redispatching for a release with an existing promotion pull request can request another Copilot review.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: grant review permissions

Copilot comment:

The final `requested_reviewers` API call switches to `GITHUB_TOKEN`, but this explicit permissions block leaves `pull-requests` at `none`. That endpoint requires pull-request write access, so the workflow will create the PR and then fail with 403 instead of requesting Copilot review. Grant `pull-requests: write` to this job.

Analysis: `copilot-requests: write` authorizes Copilot-specific requests, while the requested-reviewers pull request endpoint also requires pull request write access. The promotion job now grants both permissions to the Actions token used for the API call.

Upsides: The explicit review request can complete instead of failing with a 403 after the promotion pull request has already been created.

Downsides: The job's Actions token gains pull request write access for the duration of the promotion job.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Restore manual promotion PR behavior

Keep promotion dispatches intentionally manual: each run opens its own ready-for-review pull request, operators can close any accidental duplicate, and repository settings request Copilot automatically for non-draft pull requests.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4f8735b1-10ef-42dc-802a-78a24d24cf23

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 562cb0b5-80fe-48e5-9dc5-13348edaf303
Copilot-Session: 673d5bdc-1137-477d-8ab3-54666f695f22
Copilot-Session: 4f8735b1-10ef-42dc-802a-78a24d24cf23

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Retry transient GitHub TLS failures

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: narrow x509 retry matching

Copilot comment:

This prefix also classifies permanent verification failures (for example, an expired certificate or an unknown CA) as transient, so a runner/proxy trust misconfiguration will be retried four times and raised as `TransientGhError`. Narrow the fragment to the specific intermittent x509 failure described and covered by the test.

Analysis: The retry predicate matched every TLS certificate verification failure. Matching the observed GitHub API hostname error instead preserves that recovery path without classifying permanent certificate failures as transient, and negative tests prevent regression.

Upsides: Expired and untrusted certificates now fail immediately as permanent errors while the observed intermittent hostname mismatch remains retryable.

Downsides: A future transient TLS verification failure with different wording will require an explicit matcher.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

A review summary that only says where the review's comments came from or that
the author may push back on them was ambiguous enough that the classifier's
fail-safe kept the pull request with its author, blocking it on a note that
asks for nothing. The eval baseline already recorded this shape as flaky.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Bypass Copilot review for manual handoffs

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Clarify reviewer handoff acknowledgement

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: keep override bypass off after pushes

Copilot comment:

A push can immediately re-enable this bypass. `clear_overridden_actions()` recomputes `dashboard_override_cleared_count`/`dashboard_override_cleared_ci` from the durable command watermark on every refresh, so an old discussion or check that remains present keeps `override_cleared_actions` true even when `head_sha` changed. The new push test misses this production state because it omits both cleared fields. Treat cleared actions as a new handoff only when the command watermark is new; if the previous result already recorded a bypass for the same command and the head changed, keep the bypass off until a later command changes the watermark. Add the cleared field to the push regression test as well.

Analysis: Cleared-action facts are recomputed from the durable command timestamp, so they only represent a new manual handoff when that timestamp changes. An existing bypass now carries forward only while both the command timestamp and head SHA remain unchanged.

Upsides: A push restores the required Copilot gate even when old cleared items remain, while a later override command can establish a new manual handoff.

Downsides: No material downside identified.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: fix routed acknowledgement grammar

Copilot comment:

The comma is not grammatical for the successful `routed` branch: it now renders `@author, routed this pull request to reviewers.`, where the mention no longer serves as the subject and the remainder is a sentence fragment. Keep direct-address punctuation for the other branches, but render this case as something like `@author, this pull request was routed to reviewers.`
```
    mention = f"@{user}, " if user else ""
```

Analysis: The mention is direct address, so the successful routed branch needs a complete sentence after its comma. The acknowledgement now uses a passive sentence consistent with the other reply branches.

Upsides: Successful command acknowledgements are grammatical without changing punctuation or wording for the other outcomes.

Downsides: No material downside identified.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: distinguish same-second override commands

Copilot comment:

Commands are identified only by their second-granularity timestamp, so two authorized overrides posted in the same second are treated as the same command. If the first bypass was ended by a push, an effective second command can clear old actions but `not same_override_command` remains false, so it cannot establish a new bypass. Include the pending command ID when detecting a newly effective override, and cover two commands sharing `created_at`.
```
    same_override_command = (
        bool(facts.get("dashboard_override_since"))
        and facts.get("dashboard_override_since")
        == previous_facts.get("dashboard_override_since")
```

Analysis: The durable timestamp remains the cleared-action watermark, but a nonzero pending command ID identifies a newly effective command when timestamps collide. A pending ID is treated as the same command only when it matches the previous result; its later transition to zero remains the acknowledgement of that command.

Upsides: Distinct override commands posted in the same second can establish distinct reviewer handoffs without re-enabling an old command after a push.

Downsides: No material downside identified.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: require a pending command for fresh bypass

Copilot comment:

An old acknowledged override can regain the bypass when this PR has no cached `previous_result` (for example, after the PR was closed, evicted by `remove_cached_dashboard_prs()`, and reopened). The durable command watermark still makes `clear_overridden_actions()` report old cleared items, so `same_override_command` is false and this branch treats the old command as a new handoff—even if the current head was pushed after it. That violates the documented rule that a later push restores the gate. Only a currently pending command ID should establish a fresh bypass; acknowledged commands should only carry one forward from the same cached command/head.
```
    manual_reviewer_handoff = (
        override_cleared_actions and not same_override_command
    ) or bool(
```

Analysis: Recomputed cleared-action facts do not prove that an acknowledged command is newly effective when cached state is absent. A fresh bypass now requires a nonzero pending command ID, while an acknowledged command can only preserve a bypass already recorded for the same command watermark and head.

Upsides: Cache eviction and PR reopen flows cannot revive an old manual-review bypass after a push.

Downsides: No material downside identified.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address Copilot review comment: preserve bypass state through failures

Copilot comment:

The bypass is durable only through an immediately successful previous result. A transient discussion-classification failure returns and caches at lines 1565–1582 before this field is set, replacing the last result with facts that omit `copilot_review_bypassed_by_override`. The next successful refresh therefore restores the Copilot gate even when the command and head are unchanged; if the failure happened on the command's first refresh, `same_override_command` can also prevent that still-unacknowledged command from ever establishing the bypass. Preserve the prior bypass decision/identity in failed results (or retain the last successful routing state separately), and cover both failure-before-first-routing and failure-after-bypass refresh sequences.
```
    ) or bool(
        previous_facts.get("copilot_review_bypassed_by_override")
        and same_overridden_head
    )
```

Analysis: Classification failures are cached as the next result, so they now retain the prior command identity and bypass decision. The bypass is retained only when the command watermark and head are unchanged, while retaining the prior pending ID lets a command whose first routing attempt failed remain newly detectable.

Upsides: Transient classification failures no longer lose or prematurely consume a manual handoff, and pushes still terminate an existing bypass.

Downsides: Failed results intentionally expose the prior pending command ID as routing state until a successful refresh recomputes it.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>