Nonexistent issues get linked in commit messages and comments #12780

New Issue

GiteaMirror · 2025-11-02T10:20:48-06:00

GiteaMirror commented

2025-11-02 10:20:48 -06:00

Originally created by @Yakov5776 on GitHub (Apr 4, 2024).

Description

Currently, when users mention nonexistent issues in commit messages or comments, the system generates a hyperlink for them. However, when hovered over, these links lead to a "Network error" tooltip due to a 404 error because the referenced issue doesn't exist. This behavior can be confusing and misleading for users.

Potential Solutions:

Sub-Optimal Solution: Indicate that the issue does not exist when being hovered over in lieu of a Network error.
Optimal Solution: Issues should only be highlighted if they exist within the repository like in GitHub.

What makes the second solution more difficult is because we can't be invoking SQL queries on every page render to check the existence of a referenced issue.
GitHub internally links the issue at the time of commit or comment, not at the page render and this can be confirmed by making a new initialized repository, referencing #1 in a commit message before and after the first issue is created, and you'll only see the second commit (which is post-issue) get highlighted and linked.

Gitea Version

v1.21.10

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Git Version

No response

Operating System

No response

How are you running Gitea?

Running a fresh instance via CLI from gh-codespaces.

Database

SQLite

Originally created by @Yakov5776 on GitHub (Apr 4, 2024). ### Description Currently, when users mention nonexistent issues in commit messages or comments, the system generates a hyperlink for them. However, when hovered over, these links lead to a "Network error" tooltip due to a 404 error because the referenced issue doesn't exist. This behavior can be confusing and misleading for users. **Potential Solutions:** - **Sub-Optimal Solution:** Indicate that the issue does not exist when being hovered over in lieu of a Network error. - **Optimal Solution:** Issues should only be highlighted if they exist within the repository like in GitHub. What makes the second solution more difficult is because we can't be invoking SQL queries on every page render to check the existence of a referenced issue. GitHub internally links the issue at the time of commit or comment, not at the page render and this can be confirmed by making a new initialized repository, referencing `#1` in a commit message **before** and **after** the first issue is created, and you'll only see the second commit (which is post-issue) get highlighted and linked. ### Gitea Version v1.21.10 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots ![image](https://github.com/go-gitea/gitea/assets/28637006/8ea871f0-a635-4f33-9c30-30dfda7422b3) ![image](https://github.com/go-gitea/gitea/assets/28637006/1d51301d-41f6-49ab-85f8-d90e606f6813) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Running a fresh instance via CLI from gh-codespaces. ### Database SQLite

GiteaMirror added the type/enhancement proposal/accepted labels 2025-11-02 10:20:48 -06:00

GiteaMirror commented

2025-11-02 10:20:48 -06:00

@KN4CK3R commented on GitHub (Apr 4, 2024):

That's currently expected behaviour because the references are not checked because of performance reasons. Same for strings that look like commit hashes.

@KN4CK3R commented on GitHub (Apr 4, 2024): That's currently expected behaviour because the references are not checked because of performance reasons. Same for strings that look like commit hashes.

GiteaMirror commented

2025-11-02 10:20:49 -06:00

@silverwind commented on GitHub (Apr 4, 2024):

What we should do is at time of creation of the commit or creation/edit of a comment containing issue refs, check if the referenced issue exists, and if it does not exist, don't perform the replacement in commit message or comment.

Such a method is possible without any performance impact at rendering time and is also historically accurate so that one can not link to future issues. This is also how GitHub does it.

@silverwind commented on GitHub (Apr 4, 2024): What we should do is at time of creation of the commit or creation/edit of a comment containing issue refs, check if the referenced issue exists, and if it does not exist, don't perform the replacement in commit message or comment. Such a method is possible without any performance impact at rendering time and is also historically accurate so that one can not link to future issues. This is also how GitHub does it.

GiteaMirror commented

2025-11-02 10:20:49 -06:00

@delvh commented on GitHub (Apr 4, 2024):

Well… That does have a major drawback though, @silverwind:
If I understand your proposal correctly, it means we have to hardcode HTML into a comment.
I am not a fan of that at all, especially since it irreversibly changes what you entered.

@delvh commented on GitHub (Apr 4, 2024): Well… That does have a major drawback though, @silverwind: If I understand your proposal correctly, it means we have to hardcode HTML into a comment. I am not a fan of that at all, especially since it irreversibly changes what you entered.

GiteaMirror commented

2025-11-02 10:20:49 -06:00

@Yakov5776 commented on GitHub (Apr 4, 2024):

Same for strings that look like commit hashes.

Nope, commit hashes (short and full) are actually checked. I made sure to confirm this when making the issue.

@Yakov5776 commented on GitHub (Apr 4, 2024): > Same for strings that look like commit hashes. Nope, commit hashes (short and full) are actually checked. I made sure to confirm this when making the issue.

GiteaMirror commented

2025-11-02 10:20:49 -06:00

@Yakov5776 commented on GitHub (Apr 4, 2024):

Well… That does have a major drawback though, @silverwind: If I understand your proposal correctly, it means we have to hardcode HTML into a comment. I am not a fan of that at all, especially since it irreversibly changes what you entered.

Why HTML? it could just be hardcoding a reference which gets translated into HTML on page render.

@Yakov5776 commented on GitHub (Apr 4, 2024): > Well… That does have a major drawback though, @silverwind: If I understand your proposal correctly, it means we have to hardcode HTML into a comment. I am not a fan of that at all, especially since it irreversibly changes what you entered. Why HTML? it could just be hardcoding a _reference_ which gets translated into HTML on page render.

GiteaMirror commented

2025-11-02 10:20:50 -06:00

@silverwind commented on GitHub (Apr 4, 2024):

Well… That does have a major drawback though, @silverwind: If I understand your proposal correctly, it means we have to hardcode HTML into a comment. I am not a fan of that at all, especially since it irreversibly changes what you entered.

Indeed, that's a drawback. Also it would require commit messages to be stored in database which I think they are not currently. Still I think doing it at time of commit/comment creation is ideal, just need to find a way how to store whether a ref is valid or not and then retrieve from that store at render time.

@silverwind commented on GitHub (Apr 4, 2024): > Well… That does have a major drawback though, @silverwind: If I understand your proposal correctly, it means we have to hardcode HTML into a comment. I am not a fan of that at all, especially since it irreversibly changes what you entered. Indeed, that's a drawback. Also it would require commit messages to be stored in database which I think they are not currently. Still I think doing it at time of commit/comment creation is ideal, just need to find a way how to store whether a ref is valid or not and then retrieve from that store at render time.

GiteaMirror commented

2025-11-02 10:20:50 -06:00

@KN4CK3R commented on GitHub (Apr 4, 2024):

And it will not highlight references which are not valid at commit time.

@KN4CK3R commented on GitHub (Apr 4, 2024): And it will not highlight references which are not valid at commit time.

GiteaMirror commented

2025-11-02 10:20:50 -06:00

@silverwind commented on GitHub (Apr 4, 2024):

And it will not highlight references which are not valid at commit time.

I see that as a nice side-effect that one can not link into the future. Either way is fine with me here.

@silverwind commented on GitHub (Apr 4, 2024): > And it will not highlight references which are not valid at commit time. I see that as a nice side-effect that one can not link into the future. Either way is fine with me here.

GiteaMirror commented

2025-11-02 10:20:51 -06:00

@silverwind commented on GitHub (Apr 4, 2024):

On the other hand, existing instances with thousands of issues would not benefit from a fix that is done at commit/comment time, so likely doing it purely at render time is still ideal and arguably easier to implement as well.

@silverwind commented on GitHub (Apr 4, 2024): On the other hand, existing instances with thousands of issues would not benefit from a fix that is done at commit/comment time, so likely doing it purely at render time is still ideal and arguably easier to implement as well.

GiteaMirror commented

2025-11-02 10:20:51 -06:00

@Yakov5776 commented on GitHub (May 27, 2024):

Any updates? In the meantime, why don't we just handle "Not Found" responses?

@Yakov5776 commented on GitHub (May 27, 2024): Any updates? In the meantime, why don't we just handle "Not Found" responses?

GiteaMirror commented

2025-11-02 10:20:51 -06:00

@lunny commented on GitHub (May 27, 2024):

Yes, maybe a quick fix is the frontend can handle 404 and return a better description to end users.

@lunny commented on GitHub (May 27, 2024): Yes, maybe a quick fix is the frontend can handle 404 and return a better description to end users.

GiteaMirror commented

2025-11-02 10:20:51 -06:00

@silverwind commented on GitHub (May 27, 2024):

We could at least detect the 404 and show "It looks like this issue does not exist", that'd at least get the ugly error away as a temporary solution.

@silverwind commented on GitHub (May 27, 2024): We could at least detect the 404 and show "It looks like this issue does not exist", that'd at least get the ugly error away as a temporary solution.

GiteaMirror commented

2025-11-02 10:20:52 -06:00

@silverwind commented on GitHub (May 30, 2024):

https://github.com/go-gitea/gitea/pull/31181 will not render the popup completely on non-existant issue, so after that, the only remaining task would be to not linkify these nonexistant issues in first place on backend.

@silverwind commented on GitHub (May 30, 2024): https://github.com/go-gitea/gitea/pull/31181 will not render the popup completely on non-existant issue, so after that, the only remaining task would be to not linkify these nonexistant issues in first place on backend.

GiteaMirror commented

2025-11-02 10:20:52 -06:00

@wxiaoguang commented on GitHub (Oct 24, 2025):

For performance reason, backend render doesn't check every issue reference whether it exists (permission check is also needed, no permission also means "not found")

So the issue numbers will always get links. And we can fix the "network error" by showing "not found", proposed a new fix #35739

@wxiaoguang commented on GitHub (Oct 24, 2025): For performance reason, backend render doesn't check every issue reference whether it exists (permission check is also needed, no permission also means "not found") So the issue numbers will always get links. And we can fix the "network error" by showing "not found", proposed a new fix #35739

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12780