### Summary On a wiki page that has been renamed/moved, the Page History view lists all revisions correctly, but opening a version history or diff link from before the rename/move returns an error instead of the historical content/diff. The historical blob is intact in the repository and the request reaches Projects::WikisController#show, which returns a deliberate 404 (normal Gitaly call count/duration, no errors or retries) because the historical revision is resolved against the page's current path rather than the path in effect at that commit. This may be related to the older bug #25083 (History entries vanishing after a move into a sub-directory), but the observable symptom differs (entries remain listed here, and fail with a 404 on click), and the reproduction differs between environments (see Steps to reproduce below). I am raising this as a separate bug rather than reopening scope on #25083. The feature request #597967 ("Preserve links and history when renaming or moving wiki pages") describes closely related behavior. It's worth confirming whether that request and this bug are the same underlying concern or should stay distinct. ### Steps to reproduce Two reproduction paths were observed. The difference is the environment the behavior was reproduced (Gitlab.com or locally vs. the user's local environment), and whether #25083 also manifests. For the user, it does not. It does in my own reproduction attempts, however. **User environment (single rename is sufficient):** 1. Create a wiki page and edit it several times to build revision history. 2. Rename/move the page exactly once (confirmed via commit history: exactly one rename event for the affected page). 3. Open the page's History. 4. Click a revision that predates the rename. 5. Result: both the Version link ("This page doesn't exist. Would you like to create it?") and the Diff link (404 "Page not found") fail. **My reproduction (multiple renames required):** 1. Create a wiki page and edit it several times. 2. Rename/move the page once. This reproduces the original #25083 symptom (pre-rename entries missing from the list) rather than a 404. 3. Rename/move the page again (more than one move is required to trigger the 404 on a listed revision, since version links are missing after the first action per #25083). 4. Open the page's History and click a pre-rename revision. 5. Result: both the Version link ("This page doesn't exist. Would you like to create it?") and the Diff link (404 "Page not found") fail. ### Project * https://gitlab.com/gl-demo-ultimate-asuchodolski/examplereproproject/-/wikis/ExamplePage-original ### What is the current _bug_ behavior? * Clicking a listed pre-rename revision in wiki Page History returns a 404 / "This page doesn't exist" instead of the historical content or diff. The revision is still listed and the underlying blob exists in the repository, however the pages fail to load. ### What is the expected _correct_ behavior? * Clicking any listed revision, including revisions from before a rename/move, should display the historical content and diff for that revision, resolving against the path the page had at that commit. ### Relevant logs and/or screenshots * {width="523" height="189"} * {width="444" height="253"} * {width="433" height="133"} * {width="467" height="275"} * {width="412" height="160"} * [404Gitlab-comLogs.txt](/uploads/90de9756636efec77544b590eede8c8e/404Gitlab-comLogs.txt) [PageNotFoundGitlab-comLogs.txt](/uploads/8c27eaf202521b88081f2816cba1d198/PageNotFoundGitlab-comLogs.txt) ### Output of checks This bug happens on GitLab.com #### Results of GitLab environment info <details> <summary> Expand for output related to GitLab environment info <pre> Self-managed GitLab EE 19.1.3 (Linux package/Omnibus). Full Gitaly Cluster with Praefect (3 nodes), affected wiki repo fully replicated and healthy at time of testing. Full gitlab-rake gitlab:env:info output available in the linked support ticket. </pre> </summary></details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`sudo gitlab-rake gitlab:check SANITIZE=true\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`) (For installations from source run and paste the output of: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes * The failure is consistent with git log not following renames for wiki single-file history, so revisions predating a rename are not resolvable at the current path. Prior fix attempt !194861[ ](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/194861)targeting https://gitlab.com/gitlab-org/gitlab/-/issues/25083 enabled the --follow argument for git log on wiki repositories to address exactly this class of problem. That MR was closed unmerged. ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads).