Nonexistent issues get linked in commit messages and comments

[Yakov5776]

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

[KN4CK3R]

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

[silverwind]

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.

[delvh]

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.

[Yakov5776]

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]

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.

[silverwind]

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.

[KN4CK3R]

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

[silverwind]

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]

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.

[Yakov5776]

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

[lunny]

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