Show an alert when a note deep link targets a deleted note
What does this MR do and why?
Opening a link to a deleted note rendered the page with no feedback: the anchored note was silently absent and the reader had no way to tell a broken link from a slow page. After discussions finish loading, a #note_ anchor that matches no loaded note now raises a dismissible info alert in the standard flash container at the top of the content area: "The comment you're looking for could not be found. It may have been deleted, or you may not have permission to view it."
Design notes:
- An alert was chosen over a toast: a toast auto-dismisses and its announcement is transient, which is weak for accessibility, and this is the system explaining missing content rather than confirming a user action. Placement follows the alert component page-level guidance (the standard flash container).
- The existence check runs against the unfiltered discussions, so a live note hidden by a merge request activity filter is not misreported as deleted. The notes filter itself cannot hide the target either:
getFetchDiscussionsConfigalready forces the fetch to all-activity whenever anote_anchor is present. - Following a note link while a non-default activity filter is active resets the filter and refetches the discussions (existing behavior). The alert is suppressed while that refetch is in flight, so the briefly empty store is not misreported as a missing note.
- Navigating between two dead anchors dismisses the previous alert before showing the next, so they do not stack.
The alert copy says "could not be found" rather than "was deleted": an absent note may have been deleted, may never have existed, or may be an internal note the viewer lacks permission to see, and the client cannot distinguish these. The issue reporter proposed this variant ("cannot find note").
Scope, mapped against where a #note_ link can land:
| Surface | Renderer | Covered here |
|---|---|---|
| Merge request comments, including inline diff comments, via email or copied link | MR Overview tab, legacy notes app | Yes |
| Incidents and tickets (issue types still on the legacy view) | legacy notes app | Yes |
| Plain issue, epic, and task comments | work items viewer (separate notes system) | No: follow-up |
Explicit /diffs#note_ URLs |
Rapid Diffs or legacy diffs app | No: follow-up |
| Commit page comments | deprecated notes system | No |
The issue is surface-agnostic ("a comment's link from my email"), so this MR is one slice: the merge request email-link path plus legacy-view issues. The work items and diffs surfaces need the same treatment separately; the translated string added here is reusable as-is.
Part of #443571
References
- The issue thread, where a small UX message was endorsed by product.
Screenshots or screen recordings
| View | Before | After |
|---|---|---|
| Deep link to a deleted note (the fix) | ![]() |
![]() |
| Deep link to a live note (unchanged) | ![]() |
![]() |
Captured on the MR Overview tab at 3799a167 against merge-base 94b0c384, top-of-page framing (the alert renders in the flash container above the title). The live-note row is measured pixel-identical between before and after; the capture run also asserts no alert appears for a live note's anchor on either revision.
How to set up and validate locally
- On a merge request (or an incident-type issue), post a comment and copy its link (the timestamp anchor,
#note_<id>). - Delete the comment.
- Open the copied link in a fresh tab.
- Before: the page loads with no indication anything is missing. After: a dismissible info alert appears at the top of the content area.



