GitLab.com: Commit view shows endless spinner for files in initial commit (backend 200, UI never renders)

Summary

On gitlab.com, viewing certain initial commits in the Commits view causes specific files to show an endless loading animation where the inline file content should be rendered. The same files are accessible via blob view, "Browse files" at that SHA, and via git clone. Backend logs for the page load show HTTP 200 with no exceptions, so this appears to be a frontend/UI bug in the commit view

Steps to reproduce

Reproduced by customer

  • On gitlab.com, create a new test project.
  • Add several text files (for example, README.md, values.yaml, and another text file) to an initial commit on the default branch.
  • Push this initial commit to the project.
  • In the web UI, go to Repository -> Commits and open the first commit.
  • Scroll down to the list of files in that commit and observe how each file’s content is loaded inline in the Commits view.

What is the current bug behavior?

  • For some files in the initial commit, the inline viewer in the Commits view shows a loading spinner that never completes.
  • The spinner remains indefinitely and the file content is never rendered.
  • There is no visible error message in the UI.
  • The same files:
    • Are visible via Browse files at the same commit SHA.
    • Render correctly in the blob view (/-/blob/<SHA>/path/to/file).
    • Are present and readable when cloning the repository locally.

Backend application logs for the commit page request:

  • Show HTTP 200 responses for the commit view.
  • Do not show corresponding 4xx/5xx entries or application exceptions tied to that request.
  • Indicate that the server side successfully handled the request and returned a normal response.

This points to the commit page frontend failing to update the file component from “loading” to “loaded”, even though the underlying requests succeed.

What is the expected correct behavior?

  • In the Commits view, each file in a commit should:
    • Either render its inline content/diff, or
    • Show a clear, intentional error or limitation message (for example, “file too large”, “binary file”, “insufficient permissions”).
  • There should not be a permanent spinner in normal conditions, especially when:
    • The repository and files are valid.
    • The same paths are readable via blob view and Browse files.
    • The server returns 200 and no exceptions for the relevant requests.

Relevant logs and/or screenshots

From a browser HAR for the commit page request:

  • Main commit page request:
    • Method: GET
    • Path: /-/commit/<SHA>
    • Status: 200
    • Response headers include x-request-id and x-gitlab-meta with a correlation ID.
  • No failing XHR requests to GitLab APIs appear in the HAR for the reproduction; non‑GitLab telemetry endpoints return 200 ok.

From Kibana (GitLab.com logs), using the correlation ID from x-gitlab-meta / x-request-id:

  • Index: pubsub-rails-inf-gprd-*.
  • All matching events for that correlation ID have:
    • json.status = 200.
    • No associated json.exception.class or json.exception.message.
  • Adding json.status:[400 TO 599] to the query returns no results, confirming there are no 4xx/5xx or application exceptions associated with this page load.

This suggests the backend is behaving correctly and the bug is localized to the frontend commit view rendering logic.

Environment

  • Instance: gitlab.com (SaaS)
  • Scope: Reproducible with initial commits in newly created projects on gitlab.com.

Workaround

Users can:

All of these methods successfully display the file content; only the inline file viewer in the Commits view for the initial commit is affected.

Edited by 🤖 GitLab Bot 🤖