Reduce the occurrence of 404 Errors in the app

[Adal3n3]

The Problem

We know many customers encounter the 404 page in various ways, but the most common occurrences happen when the UI fails to load, times out, or users experience login issues. This GH issue focuses on improving the following flow:

User comes to codecov from PR > 404 > needs to login > has to navigate away to login > loses PR context.

This flow is particularly important to the product experience, as it frustrates users trying to access the app. View this issue to learn more about the pain points.

The Goal

• reduce total # of 404s

Proposed next steps

1. Investigate what are the specific reasons to trigger the 404 page from the flow? (PR > 404)
2. Reduce the # of 404 occurs has a dependency on step 1.

---

(@Adal3n3 will need to polish this issue)
Investigation note:
If the page "fails to parse," we either display the 404 page or show nothing at all.

https://codecov.sentry.io/issues/6107136679/events/5d5c6474728b4dcfb3fd2a0f6003c05d/?project=5514400&referrer=replay-errors

This investigation failed to fetch (404) issue is to find out the following questions:

1. What is the impact of the "failed to fetch" error from Sentry?
2. How often are users encountering the 404 page?
3. Are there particular patterns that trigger the 404 page most often?
4. What are the specific reasons the UI fails to load or times out that cause the majority of "failed to fetch" and "failed to parse" errors?
5. What types of login issues are causing users to encounter the 404 page?

Estimated investigation Timebox: 1 day

Dev Notes:

• Look to consolidate "failed to fetch" issue types (maybe by request URL?)
• Determine "real" number of users impacted and the impact states
  • i.e. Does a refresh fix 50%+ of users?
• Long load time could be related to large timeout value / number of retries
  • What are these values and should we fail faster?

[nicholas-codecov]

Look to consolidate "failed to fetch" issue types (maybe by request URL?)

A lot of these errors will be easier to track with the work being done migrating to rejectNetworkError so we can better track which specific data fetching services are failing and their frequencies via Sentry.

Long load time could be related to large timeout value / number of retries
What are these values and should we fail faster?

We retry three times per request, i don't believe we're timing out any requests from the API, there are a couple cases where there are looooooong requests but then succeed.