ci(review-claims): hourly sweep release backstop for restricted-token contexts

[code-yeongyu]

Summary

Follow-up to the review-claims system: live E2E surfaced that pull_request_review-triggered runs get a READ-ONLY token on fork PRs (Resource not accessible by integration, 403 on removeLabel), so the claimer's review could not release the claim label on fork PRs.

Changes

• Hourly sweep (was 6-hourly): faster self-healing.
• Sweep release backstop: when the claimer has submitted an approve/request-changes review after claiming, the sweep now releases the claim label regardless of age (runs in a trusted schedule context with a full-power token).
• Graceful 403 in release-claim: fork-PR contexts log a warning instead of failing the job; the sweep handles the release.

3-day staleness semantics unchanged.

QA

Root-caused on senpi PR #1250 (fork): claim phase verified live (gate red, reviewer auto-request, stale-review auto-clear); release via review event 403'd; this backstop closes that gap.

---

Summary by cubic

Fixes the review-claims job so claim labels are released on fork PRs, where the review-triggered run gets a read-only token and previously failed with a 403 on removeLabel. The sweep now runs hourly and doubles as a release backstop.

• removeLabel 403s in the release-claim job are logged as warnings instead of failing the job.
• The hourly sweep releases claim labels when the claimer has already approved or requested changes, regardless of label age.
• The 3-day staleness rule for expired labels is unchanged.

^{Written for commit 561a87d. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/review-claims.yml">

<violation number="1" location=".github/workflows/review-claims.yml:208">
P1: When a claimer reapplies a label while the sweep is between its reads and deletion, `reviewedSince` still describes the previous claim and removes the new claim. Revalidate or serialize the current claim generation before deleting the label.</violation>

<violation number="2" location=".github/workflows/review-claims.yml:211">
P2: When `removeLabel` fails, the catch swallows the error and the next line reports the claim as released even though it remains active. Log success only after a successful removal.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: When a claimer reapplies a label while the sweep is between its reads and deletion, reviewedSince still describes the previous claim and removes the new claim. Revalidate or serialize the current claim generation before deleting the label.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/review-claims.yml, line 208:

<comment>When a claimer reapplies a label while the sweep is between its reads and deletion, `reviewedSince` still describes the previous claim and removes the new claim. Revalidate or serialize the current claim generation before deleting the label.</comment>

<file context>
@@ -192,12 +200,18 @@ jobs:
                   Date.parse(r.submitted_at) > info.at &&
                   (r.state === 'APPROVED' || r.state === 'CHANGES_REQUESTED'));
-                if (reviewedSince) continue;
+                if (reviewedSince) {
+                  await github.rest.issues.removeLabel({ owner, repo, issue_number: pr.number, name })
+                    .catch((e) => core.info(`PR #${pr.number}: ${name} release skipped: ${e.message}`));
</file context>

[cubic-dev-ai]

P2: When removeLabel fails, the catch swallows the error and the next line reports the claim as released even though it remains active. Log success only after a successful removal.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/review-claims.yml, line 211:

<comment>When `removeLabel` fails, the catch swallows the error and the next line reports the claim as released even though it remains active. Log success only after a successful removal.</comment>

<file context>
@@ -192,12 +200,18 @@ jobs:
+                if (reviewedSince) {
+                  await github.rest.issues.removeLabel({ owner, repo, issue_number: pr.number, name })
+                    .catch((e) => core.info(`PR #${pr.number}: ${name} release skipped: ${e.message}`));
+                  core.info(`PR #${pr.number}: released ${name} — claimer ${info.actor} already reviewed (backstop for restricted-token contexts).`);
+                  continue;
+                }
</file context>