gitea icon indicating copy to clipboard operation
gitea copied to clipboard

Nonexistent issues get linked in commit messages and comments

Open Yakov5776 opened this issue 1 year ago • 13 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

image image

Git Version

No response

Operating System

No response

How are you running Gitea?

Running a fresh instance via CLI from gh-codespaces.

Database

SQLite

Yakov5776 avatar Apr 04 '24 02:04 Yakov5776

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

KN4CK3R avatar Apr 04 '24 11:04 KN4CK3R

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 avatar Apr 04 '24 18:04 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.

delvh avatar Apr 04 '24 18:04 delvh

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 avatar Apr 04 '24 19:04 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.

Yakov5776 avatar Apr 04 '24 19:04 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.

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 avatar Apr 04 '24 19:04 silverwind

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

KN4CK3R avatar Apr 04 '24 19:04 KN4CK3R

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 avatar Apr 04 '24 20:04 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.

silverwind avatar Apr 04 '24 20:04 silverwind

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

Yakov5776 avatar May 27 '24 01:05 Yakov5776

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

lunny avatar May 27 '24 01:05 lunny

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 avatar May 27 '24 20:05 silverwind

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 avatar May 30 '24 14:05 silverwind