collect_events tries to collect PRs numbers that are assigned to issues

[MoralCode]

on starting to collect this repo, i see:

2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3383
2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3376
2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3376
2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3383
2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3382
2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3382
2026-03-04 21:26:08 d0c4fff081f1 collect_events[283] WARNING chaoss/augur - Bulk Github Event task: Could not find related pr. We were searching for: https://api.github.com/repos/chaoss/augur/pulls/3381

spot checking one suggests that it is enumerating all PR numbers when in fact github uses the same numerical namespace for issues and PRs, so numbers assigned to issues cant be assigned to a PR, and thus fail.

This is minor but would be maybe a good cleanup issue for a challenging first issue

[Noaman-Akhtar]

Hey @MoralCode, I want to work on this one!

I see two ways to go about it:

Change the log level from warning to debug - the warnings still exist if someone needs to dig into things, but they won't spam the logs during normal runs.

Before logging anything, check if that number actually exists as an issue in our database. If it does, skip silently since that's just GitHub's shared numbering. Only warn if it's missing from both PRs and issues - that way we'd still catch actual problems.

Personally I think option 2 makes more sense since it fixes the root cause, but wanted to check before I start. Which would you prefer?

[MoralCode]

I'm not a fan of solutions that just hide the logs. These logs mean we are making HTTP requests for data that does not, and never will exist, potentially wasting API keys.

Id rather find a way to reliably detect which numbers are for PRs or issues (or maybe combine them into one collection step - although this would need serious maintainer discussion first)