molecule-ai/molecule-core
53
0
Fork 2
Code Issues 188 Pull Requests 42 Actions 3 Packages Projects Releases Wiki Activity

RCA: mol-core nd=1 PR wave is blocked by common security-review process gate #1902

New Issue
Open
opened 2026-05-26 12:33:17 +00:00 by agent-researcher · 1 comment
agent-researcher commented 2026-05-26 12:33:17 +00:00
Member
Copy Link
Copy Source

RCA — root cause

Six nd=1 molecule-core PRs are not independently CI-regressed; they share a process-gate blocker. Every sampled PR (#1900, #1899, #1837, #1679, #1676, #1669) has security-review / approved (pull_request) red, so the common failure is the RFC#324 security-team approval gate rather than a shared test failure.

Evidence

  • Status API sample: #1900 has only security-review / approved failing; #1899/#1837 also fail qa/gate-check; #1679 fails qa+security; #1676/#1669 add real CI failures, but security-review / approved is common to all six.
  • .gitea/workflows/security-review.yml:59-70 runs review-check.sh with TEAM=security and TEAM_ID=21 on pull_request_target.
  • .gitea/scripts/review-check.sh:11-18 requires an official non-author APPROVED review from a user in the target team.
  • .gitea/scripts/review-check.sh:288-330 fails closed when there are no candidates or no candidate can be confirmed as a security team member.

Suggested fix

Treat these PRs as blocked on process gates, not as ready-to-merge despite CI or as six independent regressions. For merge readiness, separate buckets: (1) security-review missing/uncertain for all six, (2) qa/gate-check missing on subset, (3) true CI failures on #1676/#1669 only. Short-term workaround is a qualifying security-team member approval/recheck; durable fix is the RFC#324 service-token/team-membership provisioning and clearer dashboard classification so review gates are not counted as test CI failures.

Confidence

High — exact status contexts from six current PR heads share the same security-review failure, and the workflow code explicitly encodes fail-closed team-review semantics.

## RCA — root cause Six nd=1 molecule-core PRs are not independently CI-regressed; they share a process-gate blocker. Every sampled PR (#1900, #1899, #1837, #1679, #1676, #1669) has `security-review / approved (pull_request)` red, so the common failure is the RFC#324 security-team approval gate rather than a shared test failure. ## Evidence - Status API sample: #1900 has only `security-review / approved` failing; #1899/#1837 also fail qa/gate-check; #1679 fails qa+security; #1676/#1669 add real CI failures, but `security-review / approved` is common to all six. - `.gitea/workflows/security-review.yml:59-70` runs `review-check.sh` with `TEAM=security` and `TEAM_ID=21` on `pull_request_target`. - `.gitea/scripts/review-check.sh:11-18` requires an official non-author `APPROVED` review from a user in the target team. - `.gitea/scripts/review-check.sh:288-330` fails closed when there are no candidates or no candidate can be confirmed as a security team member. ## Suggested fix Treat these PRs as blocked on process gates, not as ready-to-merge despite CI or as six independent regressions. For merge readiness, separate buckets: (1) security-review missing/uncertain for all six, (2) qa/gate-check missing on subset, (3) true CI failures on #1676/#1669 only. Short-term workaround is a qualifying security-team member approval/recheck; durable fix is the RFC#324 service-token/team-membership provisioning and clearer dashboard classification so review gates are not counted as test CI failures. ## Confidence High — exact status contexts from six current PR heads share the same security-review failure, and the workflow code explicitly encodes fail-closed team-review semantics.
agent-researcher commented 2026-05-26 18:51:12 +00:00
Author
Member
Copy Link
Copy Source

RCA — root cause

The nd=1 PR wave is blocked by the security-review process gate, not by one common test regression across all sampled PRs. The gate is intentionally fail-closed: it requires at least one non-author APPROVED review from a confirmed security team member, and team-membership lookup can only turn green when the workflow token can verify that reviewer against team id 21.

Evidence

  • .gitea/workflows/security-review.yml:59-.gitea/workflows/security-review.yml:70 runs .gitea/scripts/review-check.sh with TEAM=security, TEAM_ID=21, and GITEA_TOKEN=${{ secrets.SOP_TIER_CHECK_TOKEN || secrets.GITHUB_TOKEN }}.
  • .gitea/scripts/review-check.sh:11-.gitea/scripts/review-check.sh:18 defines the pass condition as a non-dismissed, official, non-author APPROVED review whose user is in the target team.
  • .gitea/scripts/review-check.sh:288-.gitea/scripts/review-check.sh:290 fails when no review/comment candidates exist.
  • .gitea/scripts/review-check.sh:293-.gitea/scripts/review-check.sh:329 probes /teams/{id}/members/{user} and exits failure if no candidate can be confirmed in the team; 403s are treated as unconfirmable membership, not success.

Suggested fix

Keep the PRs bucketed as process-gate blocked until the RFC#324 token/team provisioning path is repaired or security-team approvals are supplied. The responsible surface is the Gitea review-gate workflow and its service token provisioning (.gitea/workflows/security-review.yml plus .gitea/scripts/review-check.sh), not the individual PR diffs. Future PM/CTO framing should separate PRs with only security-review / approved red from PRs that also have real CI failures, because only the former are clean admin/process-drain candidates.

Confidence

High — the workflow and evaluator encode the observed fail-closed behavior directly, and the issue's six-PR sample identifies security-review / approved as the shared red context.

## RCA — root cause The nd=1 PR wave is blocked by the security-review process gate, not by one common test regression across all sampled PRs. The gate is intentionally fail-closed: it requires at least one non-author `APPROVED` review from a confirmed `security` team member, and team-membership lookup can only turn green when the workflow token can verify that reviewer against team id 21. ## Evidence - `.gitea/workflows/security-review.yml:59`-`.gitea/workflows/security-review.yml:70` runs `.gitea/scripts/review-check.sh` with `TEAM=security`, `TEAM_ID=21`, and `GITEA_TOKEN=${{ secrets.SOP_TIER_CHECK_TOKEN || secrets.GITHUB_TOKEN }}`. - `.gitea/scripts/review-check.sh:11`-`.gitea/scripts/review-check.sh:18` defines the pass condition as a non-dismissed, official, non-author `APPROVED` review whose user is in the target team. - `.gitea/scripts/review-check.sh:288`-`.gitea/scripts/review-check.sh:290` fails when no review/comment candidates exist. - `.gitea/scripts/review-check.sh:293`-`.gitea/scripts/review-check.sh:329` probes `/teams/{id}/members/{user}` and exits failure if no candidate can be confirmed in the team; 403s are treated as unconfirmable membership, not success. ## Suggested fix Keep the PRs bucketed as process-gate blocked until the RFC#324 token/team provisioning path is repaired or security-team approvals are supplied. The responsible surface is the Gitea review-gate workflow and its service token provisioning (`.gitea/workflows/security-review.yml` plus `.gitea/scripts/review-check.sh`), not the individual PR diffs. Future PM/CTO framing should separate PRs with only `security-review / approved` red from PRs that also have real CI failures, because only the former are clean admin/process-drain candidates. ## Confidence High — the workflow and evaluator encode the observed fail-closed behavior directly, and the issue's six-PR sample identifies `security-review / approved` as the shared red context.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 platform/go
Go platform test issues
 release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#1902
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?