github repo-events stream can miss PullRequestEvent.opened for newly opened PRs

[jolestar]

Summary

When opening holon-run/agentinbox PR #179 on 2026-04-20, the shared github_repo source in AgentInbox did not receive a PullRequestEvent.opened event. I checked the backing UXC stream directly and the event is missing there as well, even though adjacent repo events for the same branch and time window are present.

This appears upstream of AgentInbox inbox matching/delivery and likely needs investigation in the GitHub repo-events collection path used by UXC.

Reproduction Context

• Repo: holon-run/agentinbox
• PR: #179 feat: support webhook-only agent registration
• PR created at: 2026-04-20T13:10:52Z
• PR URL: feat: support webhook-only agent registration agentinbox#179
• Backing UXC stream: stream_affb0dc10c5977f1
• UXC stream latest offset during check: 68214

What I Observed

1. The PR exists normally on GitHub

{
  "number": 179,
  "createdAt": "2026-04-20T13:10:52Z",
  "headRefName": "issue-178",
  "headRefOid": "a98bcd1c315547e4d575ceb49ffc412c4508a703",
  "state": "OPEN"
}

Command:

gh pr view 179 --repo holon-run/agentinbox --json number,title,state,createdAt,headRefName,headRefOid,url

2. AgentInbox repo source is healthy and checkpoint has advanced

• source status: active
• runtime status: running
• checkpoint: afterOffset=68214
• lastError: null

So this does not look like a local source crash or stalled consumer.

3. The UXC stream near the PR creation time does not contain PullRequestEvent.opened for #179

I read the backing stream around the relevant time window:

uxc stream read stream_affb0dc10c5977f1 --after-offset 68150 --limit 120

Relevant events present in that slice:

• offset 68210: CreateEvent for branch issue-178, created_at=2026-04-20T13:10:31Z
• offset 68211: PushEvent on main, created_at=2026-04-20T13:21:45Z
• offset 68212: ReleaseEvent, created_at=2026-04-20T13:22:33Z
• offset 68213: PushEvent on issue-178, created_at=2026-04-20T13:22:15Z
• offset 68214: PushEvent on issue-178, created_at=2026-04-20T13:35:22Z

The expected PullRequestEvent.opened for PR #179 is not present in the stream.

4. GitHub repo events API showed the same omission in the current event window

I also checked:

gh api "repos/holon-run/agentinbox/events?per_page=30"

The result still included the branch CreateEvent at 2026-04-20T13:10:31Z and later PushEvents, but there was no PullRequestEvent.opened for #179.

Why I am filing this in UXC

AgentInbox is consuming the shared repo-events stream from UXC. Since the event is already missing in the upstream stream itself, this seems like either:

• a GitHub repo events API omission that UXC currently cannot compensate for, or
• a UXC repo-events collector gap around PR-open detection / polling / dedupe / pagination

Request

Please investigate whether the GitHub repo-events source in UXC can miss PR-open events like this, and whether we should add mitigation or fallback logic for PR creation detection.

Useful follow-up questions from my side:

• Are we relying solely on repos/{owner}/{repo}/events for PR open detection?
• If GitHub omits a PR-open event from that feed, do we have any secondary recovery path?
• Is there any polling race, dedupe, or retention edge in the UXC collector that could drop this event even when adjacent events are preserved?

[jolestar]

I checked the raw GitHub interfaces directly to separate two possibilities:

• GitHub returned a PullRequestEvent.opened and UXC lost it
• GitHub's repo-events feed itself omitted the event

For this specific incident, the evidence points to the second case.

What I verified

1. The PR exists normally on GitHub

gh pr view 179 --repo holon-run/agentinbox --json number,title,state,createdAt,headRefName,headRefOid,url

Result:

• number = 179
• createdAt = 2026-04-20T13:10:52Z
• headRefName = issue-178
• headRefOid = a98bcd1c315547e4d575ceb49ffc412c4508a703

2. The raw GitHub repo-events API does not contain PullRequestEvent.opened for #179

I fetched the repo-events feed directly from GitHub, outside UXC:

gh api 'repos/holon-run/agentinbox/events?per_page=100' --paginate

I collected 300 repo events from that feed and searched for:

• type == "PullRequestEvent"
• payload.pull_request.number == 179

Count: 0

3. Adjacent branch activity is present in the same raw feed

The same GitHub repo-events feed does contain the related branch activity around the PR creation window:

• CreateEvent for branch issue-178 at 2026-04-20T13:10:31Z
• PushEvent for refs/heads/issue-178 at 2026-04-20T13:22:15Z
• PushEvent for refs/heads/issue-178 at 2026-04-20T13:35:22Z

4. The feed does normally contain other PR-open events

So this is not a blanket "GitHub never returns PullRequestEvent.opened" problem.
In the same raw repo-events snapshot I also saw examples like:

• PullRequestEvent.opened for #177 at 2026-04-20T01:50:14Z
• PullRequestEvent.opened for #175 at 2026-04-20T00:22:47Z
• PullRequestEvent.opened for #174 at 2026-04-20T00:17:48Z

5. The PR timeline itself is active immediately after creation

I also checked the issue/PR timeline directly:

gh api 'repos/holon-run/agentinbox/issues/179/timeline?per_page=100' -H 'Accept: application/vnd.github+json'

That timeline includes follow-up activity such as:

• review_requested at 2026-04-20T13:10:53Z

So the PR was created normally on GitHub and entered subsequent workflow immediately, but the repo-events feed still did not expose the expected PullRequestEvent.opened.

Conclusion

For agentinbox#179, I do not see evidence that UXC received a PullRequestEvent.opened and then dropped it.

The current evidence says:

• the upstream GitHub repos/{owner}/{repo}/events feed itself did not include that PR-open event
• UXC therefore had nothing to ingest for that event through the current repo-events source path

What this means for UXC

This does not fully exonerate the current design, because it highlights a product gap:

• today the GitHub repo source is effectively dependent on repos/{owner}/{repo}/events
• there is no secondary recovery/reconciliation path when GitHub omits a PR-open event from that feed

So while this incident looks upstream of UXC ingestion, it still suggests we should consider mitigation in UXC, for example:

• documenting repo-events as an activity feed rather than a complete PR-open ledger
• adding a fallback/reconcile path for newly opened PRs
• possibly using a secondary PR listing/query path to backfill missed PR-open detections

So my updated read on this issue is:

• specific incident cause: likely GitHub repo-events omission
• follow-up action for UXC: still worth investigating mitigation/fallback strategy