Why is user auth still buggy?

[lolipopshock]

#355 (comment)

I thought we fixed it before? @sepo-agent

[sepo-agent-app]

It looks like a real remaining edge case, not Sherry lacking access.

The failed run for #355 was the issues event run at bec5976. The portal reached route resolution with AUTHOR_ASSOCIATION: NONE, triaged the request as implement, then the dispatch policy rejected it because implement defaults to OWNER, MEMBER, COLLABORATOR, CONTRIBUTOR only. That produced the linked denial.

We did fix related cases before: issue mentions try to refresh author_association, then promote weak associations when the actor is a repo collaborator: extract-context.ts. But this failure shows a hole in that fallback path: for a fresh issue-body mention, GitHub still resolved the requester as NONE at dispatch time, and the collaborator fallback did not promote it. Since the GitHub helper intentionally swallows best-effort API lookup failures, there was no visible diagnostic explaining which lookup failed: github.ts.

That is why retrying as a normal issue comment worked: GitHub reported the comment author as COLLABORATOR, so the same route passed auth.

Recommended fix:

• Add logging around raw event association, refreshed issue association, and collaborator fallback result.
• For issues events with weak/NONE association, verify repo permission via the permission endpoint, not only the collaborator boolean check.
• Add a regression test for: issue event says NONE, issue refresh still says NONE, requester has repo permission, dispatch should allow implement and request approval instead of denying.

So yes, “fixed before” covered part of the problem, but #355 exposed a remaining issue-body race/fallback gap.

[lolipopshock]

@sepo-agent Or maybe the action is to add a small time delay (if it fails to pass auth check)? When the author comment finished posting on the issues, then we can reliably check their auth?

[sepo-agent-app]

Yes, a small targeted delay/retry is reasonable, but I would not make it the only fix.

For issue-body mentions, the issue has already been created when the issues webhook fires, but GitHub’s derived author_association can still be stale. In #355 the router saw AUTHOR_ASSOCIATION: NONE, then dispatch denied the triaged implement route. A later issue comment from the same person came through as COLLABORATOR, so the retry worked.

The best fix is probably:

1. In extract-context, only when the trigger is an issues event and the association is weak/NONE, retry the issue refresh a few times with a short backoff before returning NONE: extract-context.ts.
2. Also use the stronger repo permission check as fallback, not just the boolean collaborator endpoint. We already have hasRepositoryPermission() for label-trigger auth, but mention fallback currently uses hasRepositoryCollaborator() instead.
3. Log the raw association, refreshed association, permission fallback result, and final association. Right now ghApi()/ghApiOk() intentionally swallow failures, so a real permission/API miss looks identical to “not a collaborator”: github.ts.
4. Add a regression test where the issue payload says NONE, the first issue API refresh still says NONE, and the later retry or permission endpoint resolves to COLLABORATOR.

So: yes to a small delay, but scoped to weak issue-author auth resolution. A blind sleep before every auth check would hide the race and slow every route; a retry + permission fallback would make the behavior deterministic and debuggable.

[lolipopshock]

Ok I'm trying to understand the rationale of why the user posting 2nd time can resolve the issue:

Isn't it because the user is added to the chat thread and then GitHub updates the data?

@sepo-agent /answer

[sepo-agent-app]

Not quite. It is probably not because the user gets “added to the chat thread.”

What likely changed is the GitHub event surface and timing:

• On the first trigger, Sepo handled an issues event from the issue body. For that event, GitHub exposed the issue author as author_association: NONE, or the follow-up API refresh still returned/stuck at NONE.
• Sepo then triaged the request as implement, and the route policy rejected NONE.
• On the second trigger, the user posted an issue_comment. GitHub includes comment.author_association on that comment object, and by then it reported COLLABORATOR, so Sepo passed auth.

So the second post helps for two reasons:

1. It is a new object/event (issue_comment) with its own author_association.
2. It happens later, after GitHub’s derived permission/association data may have settled.

The practical bug is that Sepo treats the first stale/weak NONE as authoritative too early. A retry/backoff plus repo-permission fallback for weak issue-body associations would make the first trigger behave like the second one without requiring the user to comment again.

[lolipopshock]

@sepo-agent /answer Given what we've discussed so far, what's the right next step to fix such issues?

[sepo-agent-app]

The right next step is a small targeted auth-hardening PR, not a broad workflow delay.

I’d fix the weak issue-body path in this order:

1. Add a helper in extract-context.ts for weak mention associations:

   • Only runs when GitHub reports NONE, CONTRIBUTOR, FIRST_TIMER, or FIRST_TIME_CONTRIBUTOR.
   • For issues events, retry GET /repos/{repo}/issues/{number} a few times with a short backoff.
   • If it is still weak, check GET /repos/{repo}/collaborators/{login}/permission.
   • Promote to COLLABORATOR when permission is non-empty and not none.

2. Add diagnostic logging:

   • raw event association
   • refreshed issue association
   • permission fallback result
   • final normalized association

   This matters because current best-effort GitHub API helpers hide lookup failures, so false denials are hard to distinguish from real denials.

3. Add regression tests:

   • issue body event starts as NONE, first refresh still NONE, permission endpoint says admin/write/read, final association becomes COLLABORATOR.
   • issue body event remains NONE, permission lookup fails, final association stays NONE.
   • normal comment association still passes without delay.
   • explicit route policy still rejects true unauthorized NONE.

4. Keep route authorization unchanged:

   • implement should still require trusted access.
   • The fix should only improve how Sepo determines the requester’s actual association before policy runs.

So the concrete next action is: implement bounded retry + repo-permission fallback in .agent/src/cli/extract-context.ts, with tests in .agent/src/__tests__/extract-context-cli.test.ts.

[lolipopshock]

The right next step is a small targeted auth-hardening PR, not a broad workflow delay.

I’d fix the weak issue-body path in this order:

1. Add a helper in extract-context.ts for weak mention associations:

   • Only runs when GitHub reports NONE, CONTRIBUTOR, FIRST_TIMER, or FIRST_TIME_CONTRIBUTOR.
   • For issues events, retry GET /repos/{repo}/issues/{number} a few times with a short backoff.
   • If it is still weak, check GET /repos/{repo}/collaborators/{login}/permission.
   • Promote to COLLABORATOR when permission is non-empty and not none.

2. Add diagnostic logging:

   • raw event association
   • refreshed issue association
   • permission fallback result
   • final normalized association

   This matters because current best-effort GitHub API helpers hide lookup failures, so false denials are hard to distinguish from real denials.

3. Add regression tests:

   • issue body event starts as NONE, first refresh still NONE, permission endpoint says admin/write/read, final association becomes COLLABORATOR.
   • issue body event remains NONE, permission lookup fails, final association stays NONE.
   • normal comment association still passes without delay.
   • explicit route policy still rejects true unauthorized NONE.

4. Keep route authorization unchanged:

   • implement should still require trusted access.
   • The fix should only improve how Sepo determines the requester’s actual association before policy runs.

So the concrete next action is: implement bounded retry + repo-permission fallback in .agent/src/cli/extract-context.ts, with tests in .agent/src/__tests__/extract-context-cli.test.ts.

@sepo-agent /orchestrate let's do a narrow fix for this following the plan above

[sepo-agent-app]

Sepo is dispatching follow-up automation.

Source	Next	Target	Round	Status
orchestrate	implement	Issue #358	2 / 40	Dispatched

Reason: agent planner selected implement: Issue #358 requests a small, self-contained auth-hardening change in the current issue; no child issue or broader workflow is needed.

[sepo-agent-app]

Sepo implementation finished

• Branch: agent/implement-issue-358/codex-26677788726
• Pull request: Harden issue-body auth association fallback #372

Implemented bounded weak mention association resolution for issue-body events: issue association refresh now retries briefly, falls back to the repository permission endpoint, logs each auth-resolution step, and preserves route policy checks. Added regression coverage for permission promotion/failure, strong comment fast-path behavior, and unauthorized NONE implement rejection; verified with build and focused tests.

[github-actions]

Closing because this agent issue has had no activity for 30 days.