gitea
gitea copied to clipboard
Nonexistent issues get linked in commit messages and comments
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
That's currently expected behaviour because the references are not checked because of performance reasons. Same for strings that look like commit hashes.
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.
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.
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.
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.
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.
And it will not highlight references which are not valid at commit time.
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.
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.
Any updates? In the meantime, why don't we just handle "Not Found" responses?
Yes, maybe a quick fix is the frontend can handle 404 and return a better description to end users.
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.
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.