Skip to content

Open Issue Counter becomes offset #11823

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 of 7 tasks
alexander-zierhut opened this issue Jun 9, 2020 · 7 comments · Fixed by #12900
Closed
2 of 7 tasks

Open Issue Counter becomes offset #11823

alexander-zierhut opened this issue Jun 9, 2020 · 7 comments · Fixed by #12900
Labels
issue/duplicate The issue has already been reported.

Comments

@alexander-zierhut
Copy link

Description

When closing issues using a commit message, for example Changed some stuff Closes #1 Closes #2, the open issue count does not change to portrait the new changes. This fixes itself when closing another issue manually using the webinterface.

Screenshots

try.gitea.io Private installation
image image
@alexander-zierhut
Copy link
Author

This still exists in the newest version I have updated to.

@iamdoubz
Copy link

I have this issue in 1.12.4. But, if I close the issue with a pull request in the web interface, the number is not correct until I restart the server then the number is correct.

@warnat
Copy link

warnat commented Sep 17, 2020

There is a cron (?) job running every 24 hours, to correct that value. The function is called CheckRepoStats.
In the Administration->Monitoring, there is a button for that: "Check all repository statistics".
I must admit, that I cannot find the root cause for the problem.

@alexander-zierhut
Copy link
Author

There is a cron (?) job running every 24 hours, to correct that value I was going to mention that as the server does not have to be restarted to fix this problem. It gets fixed after sometime.

@alexander-zierhut
Copy link
Author

I cannot find the root cause for the problem. @warnat Have you thought about a caching issue?

@warnat
Copy link

warnat commented Sep 18, 2020

there is someone working on.
see #10536

zeripath added a commit to zeripath/gitea that referenced this issue Sep 19, 2020
We should only update is_empty, default_branch and updated time columns
during commitRepoAction and not update other columns as we risk
overwriting incorrect information.

Fix go-gitea#11823
Fix go-gitea#10536

Signed-off-by: Andrew Thornton <[email protected]>
@zeripath zeripath added the issue/duplicate The issue has already been reported. label Sep 19, 2020
@zeripath
Copy link
Contributor

Duplicate of #10536

@zeripath zeripath marked this as a duplicate of #10536 Sep 19, 2020
techknowlogick added a commit that referenced this issue Sep 20, 2020
We should only update is_empty, default_branch and updated time columns
during commitRepoAction and not update other columns as we risk
overwriting incorrect information.

Fix #11823
Fix #10536

Signed-off-by: Andrew Thornton <[email protected]>

Co-authored-by: techknowlogick <[email protected]>
zeripath added a commit to zeripath/gitea that referenced this issue Sep 20, 2020
Backport go-gitea#12900

We should only update is_empty, default_branch and updated time columns
during commitRepoAction and not update other columns as we risk
overwriting incorrect information.

Fix go-gitea#11823
Fix go-gitea#10536

Signed-off-by: Andrew Thornton <[email protected]>
lunny pushed a commit that referenced this issue Sep 21, 2020
Backport #12900

We should only update is_empty, default_branch and updated time columns
during commitRepoAction and not update other columns as we risk
overwriting incorrect information.

Fix #11823
Fix #10536

Signed-off-by: Andrew Thornton <[email protected]>
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/duplicate The issue has already been reported.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants