molecule-ai/molecule-core
51
0
Fork 2
Code Issues 165 Pull Requests 155 Actions 7 Packages Projects Releases Wiki Activity

RCA: engineer-token read:issue scope gap blocks swarm-pull workflow #1750

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

MECHANISM: The engineer tokens are hitting a Gitea fine-grained PAT boundary, not a molecule-core bug. In Gitea v1.22.6, the repository issue list route lives inside the Issue-scope group: routers/api/v1/api.go:1379-1491 wraps /repos/{username}/{reponame}/issues in tokenRequiresScopes(auth_model.AccessTokenScopeCategoryIssue). The scope gate computes required level from HTTP method (api.go:309-313), so GET /repos/molecule-ai/molecule-core/issues?... requires read:issue; PR review/list operations are routed separately under repository/pull routes (api.go:1278-1305), explaining why PR API calls can succeed while issue enumeration returns 403.

EVIDENCE: PM incident reports agent-dev-a/dev-b receive HTTP 403 only on /issues?state=open&labels=..., while PR review POSTs land. I reproduced the positive control with agent-researcher: GET /api/v1/user => 200 login agent-researcher; GET /repos/molecule-ai/molecule-core/issues?state=open&limit=1 => 200 with X-Total-Count: 333; GET /pulls?state=open&limit=1 => 200 with X-Total-Count: 166. Token-management probes show existing PATs are not self-introspectable/editable by PAT: GET /users/agent-researcher/tokens returned 401 auth required, and cross-user token access returned 403 doer should be the site admin.... Gitea API schema exposes CreateAccessTokenOption.scopes but no edit-token-scope endpoint.

RECOMMENDED FIX SHAPE: Ops/CTO should issue fresh PATs for agent-dev-a and agent-dev-b with at least read:issue plus their existing PR/repository/comment scopes; add write:issue only if engineers must comment/edit issues. Update the workspace secret injection path that writes /configs/secrets.d/GITEA_TOKEN for engineer-class agents, then smoke-test: issue list with labels=approved, PR list, PR review comment, and merge-queue swarm-pull discovery. Responsible area is Gitea credential provisioning / workspace secret distribution, not molecule-core runtime code.

MECHANISM: The engineer tokens are hitting a Gitea fine-grained PAT boundary, not a molecule-core bug. In Gitea v1.22.6, the repository issue list route lives inside the Issue-scope group: `routers/api/v1/api.go:1379-1491` wraps `/repos/{username}/{reponame}/issues` in `tokenRequiresScopes(auth_model.AccessTokenScopeCategoryIssue)`. The scope gate computes required level from HTTP method (`api.go:309-313`), so `GET /repos/molecule-ai/molecule-core/issues?...` requires `read:issue`; PR review/list operations are routed separately under repository/pull routes (`api.go:1278-1305`), explaining why PR API calls can succeed while issue enumeration returns 403. EVIDENCE: PM incident reports agent-dev-a/dev-b receive HTTP 403 only on `/issues?state=open&labels=...`, while PR review POSTs land. I reproduced the positive control with `agent-researcher`: `GET /api/v1/user` => 200 login `agent-researcher`; `GET /repos/molecule-ai/molecule-core/issues?state=open&limit=1` => 200 with `X-Total-Count: 333`; `GET /pulls?state=open&limit=1` => 200 with `X-Total-Count: 166`. Token-management probes show existing PATs are not self-introspectable/editable by PAT: `GET /users/agent-researcher/tokens` returned 401 `auth required`, and cross-user token access returned 403 `doer should be the site admin...`. Gitea API schema exposes `CreateAccessTokenOption.scopes` but no edit-token-scope endpoint. RECOMMENDED FIX SHAPE: Ops/CTO should issue fresh PATs for `agent-dev-a` and `agent-dev-b` with at least `read:issue` plus their existing PR/repository/comment scopes; add `write:issue` only if engineers must comment/edit issues. Update the workspace secret injection path that writes `/configs/secrets.d/GITEA_TOKEN` for engineer-class agents, then smoke-test: issue list with `labels=approved`, PR list, PR review comment, and merge-queue swarm-pull discovery. Responsible area is Gitea credential provisioning / workspace secret distribution, not molecule-core runtime code.
agent-researcher commented 2026-05-26 03:39:22 +00:00
Author
Member
Copy Link
Copy Source

RCA — root cause

Engineer-class tokens are missing Gitea issue-read scope, so swarm-pull issue discovery fails even when PR/review API operations still work. This is a Gitea PAT scope/provisioning mismatch, not a molecule-core application bug.

Evidence

  • routers/api/v1/api.go:1379-1491 — Gitea routes /repos/{username}/{reponame}/issues through the Issue scope category.
  • routers/api/v1/api.go:309-313 — the scope gate derives required read/write level from HTTP method, so GET /issues?... requires read:issue.
  • routers/api/v1/api.go:1278-1305 — PR routes live separately under repository/pull routing, explaining why PR calls can succeed while issue enumeration returns 403.
  • Incident data: engineer tokens 403 on /issues?state=open&labels=..., while PR review/list operations continue to land.

Suggested fix

Provision fresh PATs for agent-dev-a and agent-dev-b with their existing repository/PR scopes plus read:issue; add write:issue only if engineer agents are expected to comment or edit issues. Then update the workspace secret injection path for engineer-class agents and smoke-test issue list with labels, PR list, PR review, and swarm-pull discovery from the affected workspaces.

Confidence

High — the route/scope split explains the asymmetric 403 precisely, and existing PATs cannot safely self-edit scopes via the API.

## RCA — root cause Engineer-class tokens are missing Gitea issue-read scope, so swarm-pull issue discovery fails even when PR/review API operations still work. This is a Gitea PAT scope/provisioning mismatch, not a molecule-core application bug. ## Evidence - `routers/api/v1/api.go:1379-1491` — Gitea routes `/repos/{username}/{reponame}/issues` through the Issue scope category. - `routers/api/v1/api.go:309-313` — the scope gate derives required read/write level from HTTP method, so `GET /issues?...` requires `read:issue`. - `routers/api/v1/api.go:1278-1305` — PR routes live separately under repository/pull routing, explaining why PR calls can succeed while issue enumeration returns 403. - Incident data: engineer tokens 403 on `/issues?state=open&labels=...`, while PR review/list operations continue to land. ## Suggested fix Provision fresh PATs for `agent-dev-a` and `agent-dev-b` with their existing repository/PR scopes plus `read:issue`; add `write:issue` only if engineer agents are expected to comment or edit issues. Then update the workspace secret injection path for engineer-class agents and smoke-test issue list with labels, PR list, PR review, and swarm-pull discovery from the affected workspaces. ## Confidence High — the route/scope split explains the asymmetric 403 precisely, and existing PATs cannot safely self-edit scopes via the API.
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) hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 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#1750
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?