The core issue: GitHub's Search API runs on a separate index from the main REST API. That index is not real-time — it has a lag, sometimes minutes, sometimes longer during high-traffic periods. So when you create or update a PR and immediately search for it, you're querying stale data. The PR exists, the main API knows about it, but Search hasn't indexed it yet.
This means GET /search/issues?q=is:pr and GET /repos/{owner}/{repo}/pulls can return genuinely different results for the same repository at the same point in time. It's not a bug in your code — it's an architectural reality of how GitHub's search works.
Specific things that trip people up:

• Newly opened PRs not appearing for 30-60 seconds after creation
• Recently merged PRs still showing as open in search results
• Label or assignee filters returning stale matches
• Repo forks sometimes indexed under wrong parent
  What I do instead:

For anything requiring accuracy — use GET /repos/{owner}/{repo}/pulls with filters, not the Search API
Use Search only for discovery across repos where slight staleness is acceptable
If you absolutely need Search, build in a retry with exponential backoff and accept eventual consistency

One thing worth knowing: the Search API also has a stricter rate limit — 30 requests/minute authenticated vs 10 unauthenticated — completely separate from the REST API's limits. So if you're hitting both in the same app, track them independently.

Treat GitHub Search like a search engine, not a database. It's fast and powerful for discovery, but eventual consistency is the contract, not an exception.