Comment history is loading slowly + has an offByOne error #8114

New Issue

GiteaMirror · 2025-11-02T07:54:17-06:00

GiteaMirror commented

2025-11-02 07:54:17 -06:00

Originally created by @delvh on GitHub (Nov 17, 2021).

Gitea Version

1.16.0+dev-519-g3be156f66

Operating System

Linux

Browser Version

Firefox 94.0

Can you reproduce the bug on the Gitea demo site?

Yes

Description

Gitea now supports the comment history.
However, loading the history seems to be way too slow:

For normal comments, the history will automatically be loaded once the page is reloaded.
Fine so far. Still with a hefty delay (~3 seconds, so you definitely notice when the history suddenly appears), but it loads.

The issue bodies (the description of the issue) are way worse:
According to my tests on try.gitea.io, there seems to be an index error for those, as they only load once a second edit has been made. Once the second edit has been made, it behaves like a normal comment.

So, two things should be done:

the offByOne error should be fixed.
the history should be loaded faster, at best to the point that it is unnoticeable that it has been loaded afterwards.

Screenshots

This is an issue description where one edit has been made and the page has been force-reloaded. As you see, the history is not getting displayed.

Originally created by @delvh on GitHub (Nov 17, 2021). ### Gitea Version 1.16.0+dev-519-g3be156f66 ### Operating System Linux ### Browser Version Firefox 94.0 ### Can you reproduce the bug on the Gitea demo site? Yes ### Description Gitea now supports the comment history. However, loading the history seems to be **way too slow**: For normal comments, the history will automatically be loaded once the page is reloaded. Fine so far. Still with a hefty delay (~3 seconds, so you definitely notice when the history suddenly appears), but it loads. The issue bodies (the description of the issue) are way worse: According to my tests on try.gitea.io, there seems to be an index error for those, as they only load once a second edit has been made. Once the second edit has been made, it behaves like a normal comment. So, two things should be done: 1. the offByOne error should be fixed. 2. the history should be loaded faster, at best to the point that it is unnoticeable that it has been loaded afterwards. ### Screenshots ![image](https://user-images.githubusercontent.com/51889757/142085420-58df89c7-3bbd-4a57-820c-4e1195095331.png) This is an issue description where one edit has been made and the page has been force-reloaded. As you see, the history is not getting displayed.

GiteaMirror added the performance/speed topic/ui-interaction issue/needs-feedback type/bug labels 2025-11-02 07:54:17 -06:00

GiteaMirror closed this issue

2025-11-02 07:54:18 -06:00

GiteaMirror commented

2025-11-02 07:54:18 -06:00

@jpraet commented on GitHub (Nov 20, 2021):

I think the offByOne happens when editing old issues/comments (created before there was support for edit history).

@jpraet commented on GitHub (Nov 20, 2021): I think the offByOne happens when editing old issues/comments (created before there was support for edit history).

GiteaMirror commented

2025-11-02 07:54:19 -06:00

@wxiaoguang commented on GitHub (Nov 20, 2021):

I think the offByOne happens when editing old issues/comments (created before there was support for edit history).

👍 Yep, the history menu won't be shown if there is only one history revision (that's by design).

For old comments, there was no history revision before, so the first editing would save the first history revision, and the menu would only be shown for the second editing.

@wxiaoguang commented on GitHub (Nov 20, 2021): > I think the offByOne happens when editing old issues/comments (created before there was support for edit history). 👍 Yep, the history menu won't be shown if there is only one history revision (that's by design). For old comments, there was no history revision before, so the first editing would save the first history revision, and the menu would only be shown for the second editing.

GiteaMirror commented

2025-11-02 07:54:19 -06:00

@wxiaoguang commented on GitHub (Nov 20, 2021):

And I haven't noticed any performance problem on my Gitea instance. The menu is always shown within 1 second.

If you believe there is a performance problem, please make sure your network is fast enough and help to find which function/sql causes the laggy.

@wxiaoguang commented on GitHub (Nov 20, 2021): And I haven't noticed any performance problem on my Gitea instance. The menu is always shown within 1 second. If you believe there is a performance problem, please make sure your network is fast enough and help to find which function/sql causes the laggy.

GiteaMirror commented

2025-11-02 07:54:19 -06:00

@jpraet commented on GitHub (Nov 20, 2021):

To support edit history for existing comments: maybe the issue_content_history can be initialized with the initial (is_first_created) content when editing a comment that does not have such an entry yet?

@jpraet commented on GitHub (Nov 20, 2021): To support edit history for existing comments: maybe the issue_content_history can be initialized with the initial (is_first_created) content when editing a comment that does not have such an entry yet?

GiteaMirror commented

2025-11-02 07:54:19 -06:00

@wxiaoguang commented on GitHub (Nov 20, 2021):

To support edit history for existing comments: maybe the issue_content_history can be initialized with the initial (is_first_created) content when editing a comment that does not have such an entry yet?

Agree, it would work.

@wxiaoguang commented on GitHub (Nov 20, 2021): > To support edit history for existing comments: maybe the issue_content_history can be initialized with the initial (is_first_created) content when editing a comment that does not have such an entry yet? Agree, it would work.

GiteaMirror commented

2025-11-02 07:54:19 -06:00

@jpraet commented on GitHub (Nov 21, 2021):

Or the issue_content_history could only be populated with the previous value when actually making an edit?
Because with the current implementation all issue contents and comments are unnecessarily saved twice in the database.

@jpraet commented on GitHub (Nov 21, 2021): Or the issue_content_history could only be populated with the previous value when actually making an edit? Because with the current implementation all issue contents and comments are unnecessarily saved twice in the database.

GiteaMirror commented

2025-11-02 07:54:19 -06:00

@wxiaoguang commented on GitHub (Nov 21, 2021):

Or the issue_content_history could only be populated with the previous value when actually making an edit? Because with the current implementation all issue contents and comments are unnecessarily saved twice in the database.

I have thought about it, but it would make the algorithm more complex (eg: list/diff), usually I prefer a simple and clear solution. And issue contents are much smaller than git repositories, saving the contents won't cost too much in modern days.

@wxiaoguang commented on GitHub (Nov 21, 2021): > Or the issue_content_history could only be populated with the previous value when actually making an edit? Because with the current implementation all issue contents and comments are unnecessarily saved twice in the database. I have thought about it, but it would make the algorithm more complex (eg: list/diff), usually I prefer a simple and clear solution. And issue contents are much smaller than git repositories, saving the contents won't cost too much in modern days.

GiteaMirror commented

2025-11-02 07:54:20 -06:00

@wxiaoguang commented on GitHub (Nov 22, 2021):

I think this issue can be closed by #17746

The "performance" problem may not be related. If there is really a performance problem, we need more details (and a separate issue)

@wxiaoguang commented on GitHub (Nov 22, 2021): I think this issue can be closed by #17746 The "performance" problem may not be related. If there is really a performance problem, we need more details (and a separate issue)

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#8114