Loading
Guard repository page entrypoints against degraded rendering
What does this MR do and why?
Adds null guards to seven frontend page entrypoints so they no-op when their mount-point elements are missing.
Since the graceful Gitaly degradation rollout (https://gitlab.com/gitlab-org/gitlab/-/issues/591106), repository pages can render a degraded 503 layout that omits the JS mount points. The page entrypoints still run unconditionally and read those elements without null checks, so every visit to an affected page during a Gitaly outage throws a TypeError that is reported to Sentry.
Pages fixed and the Sentry issues they resolve (user counts from a 24h sample):
| Page | Error | Sentry issue | Users/day |
|---|---|---|---|
| Commit | Cannot read properties of null (reading 'innerHTML') |
GITLABCOM-CLIENTSIDE-2JZMA | 1,019 |
| Repository tree | Cannot destructure property 'dataset' of 'e' as it is null |
GITLABCOM-CLIENTSIDE-2MD87, 2MD98, 2MD9E | ~88 |
| Compare | Cannot read properties of null (reading 'dataset') |
GITLABCOM-CLIENTSIDE-2MD8G, 2MD97 | ~25 |
| Blame | Cannot read properties of null (reading 'dataset') |
GITLABCOM-CLIENTSIDE-2MD99 | 2 |
| Find file | same pattern | preventive, no events in sampled window | — |
| MR conflicts | same pattern | preventive, no events in sampled window | — |
The EE repository wrapper (ee/app/assets/javascripts/repository/index.js) destructures the CE initTree() return value, so it gets its own guard for the now-nullable return.
Healthy pages are unchanged; degraded pages simply stop throwing.
References
- https://gitlab.com/gitlab-org/gitlab/-/issues/591106 (graceful Gitaly degradation)
- https://new-sentry.gitlab.net/organizations/gitlab/issues/3676366/
How to set up and validate locally
- In GDK, stop Gitaly:
gdk stop gitaly - Visit a project commit page, repository tree, compare page, or blame page.
- The degraded "Unable to load" message renders; the browser console shows no
TypeErrorfrom the page entrypoint.
Screenshots or screen recordings
No visual changes.