github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-09 12:46:42 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Unable to create new issues due to bad import from Trac #3320

New Issue
Closed
opened 2025-11-02 05:08:04 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-11-02 05:08:04 -06:00
Owner
Copy Link

Originally created by @ctrlaltca on GitHub (May 13, 2019).

  • Gitea version (or commit ref): 1.8.1
  • Git version: 2.14.5
  • Operating system: Slackware64 14.2
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

I can't create a new issue, I receive a 500 error.
error log:

2019/05/13 09:45:36 [T] AppPath: /usr/local/bin/gitea
2019/05/13 09:45:36 [T] AppWorkPath: /var/lib/gitea
2019/05/13 09:45:36 [T] Custom path: /var/lib/gitea/custom
2019/05/13 09:45:36 [T] Log path: /var/lib/gitea/log
[Macaron] 2019-05-13 09:45:46: Started GET /Organization/reponame/issues/new for 10.0.252.14
[Macaron] 2019-05-13 09:45:46: Completed GET /Organization/reponame/issues/new 200 OK in 55.190103ms
[Macaron] 2019-05-13 09:45:46: Started GET /vendor/assets/octicons/octicons.min.css for 10.0.252.14
...
[Macaron] 2019-05-13 09:46:07: Started POST /Organization/reponame/issues/new for 10.0.252.14
[Macaron] 2019-05-13 09:46:07: Completed POST /Organization/reponame/issues/new 500 Internal Server Error in 32.11754ms

I found these messages on gitea.log:

2019/05/13 09:48:15 [...outers/repo/issue.go:557 NewIssuePost()] [E] NewIssue: newIssue: Error 1062: Duplicate entry '5-333' for key 'UQE_issue_repo_index'

Xorm.log:

2019/05/13 09:48:15 [I] [SQL] INSERT INTO `issue` (`repo_id`,`index`,`poster_id`,`name`,`content`,`milestone_id`,`priority`,`is_closed`,`is_pull`,`num_comments`,`ref`,`deadline_unix`,`created_unix`,`updated_unix`,`closed_unix`,`is_locked`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) []interface {}{5, 333, 1, "Issue title", "VIssue body", 0, 0, false, false, 0, "", 0, 1557733695, 1557733695, 0, false}

I then tried to run the same query from mysql CLI, and in fact i receive the same error:

MariaDB [gitea]> INSERT INTO `issue` (`repo_id`,`index`,`poster_id`,`name`,`content`,`milestone_id`,`priority`,`is_closed`,`is_pull`,`num_comments`,`ref`,`deadline_unix`,`created_unix`,`updated_unix`,`closed_, 1557733695, 0, false);S (5, 333, 1, "Issue title", "Issue body", 0, 0, false, false, 0, "", 0, 1557733695 
ERROR 1062 (23000): Duplicate entry '5-333' for key 'UQE_issue_repo_index'

This is the result of SHOW CREATE TABLE issue

CREATE TABLE `issue` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `repo_id` bigint(20) DEFAULT NULL,
  `index` bigint(20) DEFAULT NULL,
  `poster_id` bigint(20) DEFAULT NULL,
  `name` varchar(255) DEFAULT NULL,
  `content` text,
  `milestone_id` bigint(20) DEFAULT NULL,
  `priority` int(11) DEFAULT NULL,
  `is_closed` tinyint(1) DEFAULT NULL,
  `is_pull` tinyint(1) DEFAULT NULL,
  `num_comments` int(11) DEFAULT NULL,
  `ref` varchar(255) DEFAULT NULL,
  `deadline_unix` bigint(20) DEFAULT NULL,
  `created_unix` bigint(20) DEFAULT NULL,
  `updated_unix` bigint(20) DEFAULT NULL,
  `closed_unix` bigint(20) DEFAULT NULL,
  `is_locked` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `UQE_issue_repo_index` (`repo_id`,`index`),
  KEY `IDX_issue_created_unix` (`created_unix`),
  KEY `IDX_issue_milestone_id` (`milestone_id`),
  KEY `IDX_issue_is_closed` (`is_closed`),
  KEY `IDX_issue_updated_unix` (`updated_unix`),
  KEY `IDX_issue_closed_unix` (`closed_unix`),
  KEY `IDX_issue_deadline_unix` (`deadline_unix`),
  KEY `IDX_issue_repo_id` (`repo_id`),
  KEY `IDX_issue_poster_id` (`poster_id`),
  KEY `IDX_issue_is_pull` (`is_pull`)
) ENGINE=InnoDB AUTO_INCREMENT=969 DEFAULT CHARSET=utf8

And in fact an issue with repo_id=5 and index=333 already exists:

MariaDB [gitea]> select id, repo_id, `index`, poster_id, created_unix, updated_unix, closed_unix, is_locked from issue where repo_id=5 and `index`=333;
+-----+---------+-------+-----------+--------------+--------------+-------------+-----------+
| id  | repo_id | index | poster_id | created_unix | updated_unix | closed_unix | is_locked |
+-----+---------+-------+-----------+--------------+--------------+-------------+-----------+
| 333 |       5 |   333 |         4 |   1334232689 |   1338988990 |  1338988976 |         0 |
+-----+---------+-------+-----------+--------------+--------------+-------------+-----------+

The max value of index in the issues table is 966:

MariaDB [gitea]> select max(`index`) from issue where repo_id=5;
+--------------+
| max(`index`) |
+--------------+
|          966 |
+--------------+

I've tried to make my way inside models/issue.go to understand how the index to be used is determined, but unsuccessfully.

Screenshots

Schermata 2019-05-13 alle 09 53 36

Originally created by @ctrlaltca on GitHub (May 13, 2019). - Gitea version (or commit ref): 1.8.1 - Git version: 2.14.5 - Operating system: Slackware64 14.2 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description I can't create a new issue, I receive a 500 error. error log: ``` 2019/05/13 09:45:36 [T] AppPath: /usr/local/bin/gitea 2019/05/13 09:45:36 [T] AppWorkPath: /var/lib/gitea 2019/05/13 09:45:36 [T] Custom path: /var/lib/gitea/custom 2019/05/13 09:45:36 [T] Log path: /var/lib/gitea/log [Macaron] 2019-05-13 09:45:46: Started GET /Organization/reponame/issues/new for 10.0.252.14 [Macaron] 2019-05-13 09:45:46: Completed GET /Organization/reponame/issues/new 200 OK in 55.190103ms [Macaron] 2019-05-13 09:45:46: Started GET /vendor/assets/octicons/octicons.min.css for 10.0.252.14 ... [Macaron] 2019-05-13 09:46:07: Started POST /Organization/reponame/issues/new for 10.0.252.14 [Macaron] 2019-05-13 09:46:07: Completed POST /Organization/reponame/issues/new 500 Internal Server Error in 32.11754ms ``` I found these messages on gitea.log: ``` 2019/05/13 09:48:15 [...outers/repo/issue.go:557 NewIssuePost()] [E] NewIssue: newIssue: Error 1062: Duplicate entry '5-333' for key 'UQE_issue_repo_index' ``` Xorm.log: ``` 2019/05/13 09:48:15 [I] [SQL] INSERT INTO `issue` (`repo_id`,`index`,`poster_id`,`name`,`content`,`milestone_id`,`priority`,`is_closed`,`is_pull`,`num_comments`,`ref`,`deadline_unix`,`created_unix`,`updated_unix`,`closed_unix`,`is_locked`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) []interface {}{5, 333, 1, "Issue title", "VIssue body", 0, 0, false, false, 0, "", 0, 1557733695, 1557733695, 0, false} ``` I then tried to run the same query from mysql CLI, and in fact i receive the same error: ``` MariaDB [gitea]> INSERT INTO `issue` (`repo_id`,`index`,`poster_id`,`name`,`content`,`milestone_id`,`priority`,`is_closed`,`is_pull`,`num_comments`,`ref`,`deadline_unix`,`created_unix`,`updated_unix`,`closed_, 1557733695, 0, false);S (5, 333, 1, "Issue title", "Issue body", 0, 0, false, false, 0, "", 0, 1557733695 ERROR 1062 (23000): Duplicate entry '5-333' for key 'UQE_issue_repo_index' ``` This is the result of `SHOW CREATE TABLE issue` ```sql CREATE TABLE `issue` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `repo_id` bigint(20) DEFAULT NULL, `index` bigint(20) DEFAULT NULL, `poster_id` bigint(20) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, `content` text, `milestone_id` bigint(20) DEFAULT NULL, `priority` int(11) DEFAULT NULL, `is_closed` tinyint(1) DEFAULT NULL, `is_pull` tinyint(1) DEFAULT NULL, `num_comments` int(11) DEFAULT NULL, `ref` varchar(255) DEFAULT NULL, `deadline_unix` bigint(20) DEFAULT NULL, `created_unix` bigint(20) DEFAULT NULL, `updated_unix` bigint(20) DEFAULT NULL, `closed_unix` bigint(20) DEFAULT NULL, `is_locked` tinyint(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `UQE_issue_repo_index` (`repo_id`,`index`), KEY `IDX_issue_created_unix` (`created_unix`), KEY `IDX_issue_milestone_id` (`milestone_id`), KEY `IDX_issue_is_closed` (`is_closed`), KEY `IDX_issue_updated_unix` (`updated_unix`), KEY `IDX_issue_closed_unix` (`closed_unix`), KEY `IDX_issue_deadline_unix` (`deadline_unix`), KEY `IDX_issue_repo_id` (`repo_id`), KEY `IDX_issue_poster_id` (`poster_id`), KEY `IDX_issue_is_pull` (`is_pull`) ) ENGINE=InnoDB AUTO_INCREMENT=969 DEFAULT CHARSET=utf8 ``` And in fact an issue with repo_id=5 and index=333 already exists: ``` MariaDB [gitea]> select id, repo_id, `index`, poster_id, created_unix, updated_unix, closed_unix, is_locked from issue where repo_id=5 and `index`=333; +-----+---------+-------+-----------+--------------+--------------+-------------+-----------+ | id | repo_id | index | poster_id | created_unix | updated_unix | closed_unix | is_locked | +-----+---------+-------+-----------+--------------+--------------+-------------+-----------+ | 333 | 5 | 333 | 4 | 1334232689 | 1338988990 | 1338988976 | 0 | +-----+---------+-------+-----------+--------------+--------------+-------------+-----------+ ``` The max value of `index` in the issues table is 966: ``` MariaDB [gitea]> select max(`index`) from issue where repo_id=5; +--------------+ | max(`index`) | +--------------+ | 966 | +--------------+ ``` I've tried to make my way inside `models/issue.go` to understand how the index to be used is determined, but unsuccessfully. ## Screenshots ![Schermata 2019-05-13 alle 09 53 36](https://user-images.githubusercontent.com/1631111/57604656-00f95e00-7565-11e9-8f87-f1d5afcf33c9.png)
GiteaMirror commented 2025-11-02 05:08:05 -06:00
Author
Owner
Copy Link

@ctrlaltca commented on GitHub (May 13, 2019):

I've found out NextIssueIndex() in repo.go.
Looks like the script i used to import the issues from an old instance of Trac kept the original ticket numbers and this caused the issue counter to be 966, even if the total number of issues in the repo is 332 (number of PRs is 0):

MariaDB [gitea]> select max(`index`), count(*) from issue where repo_id=5;
+--------------+----------+
| max(`index`) | count(*) |
+--------------+----------+
|          966 |      332 |
+--------------+----------+

Trac's multiple repository support is just a bad hack, and it shares the issue counter for all the issues across all the repositories.
I'm afraid the only solution is to manually renumber the issues so that their indexes are consecutive.
Feel free to close this, but if you have any suggestion I'll be glad to hear it.
Thank you

@ctrlaltca commented on GitHub (May 13, 2019): I've found out [NextIssueIndex()](https://github.com/go-gitea/gitea/blob/ce8de3533485eed0c56059d6334a5031a73eed67/models/repo.go#L734) in `repo.go`. Looks like the script i used to import the issues from an old instance of Trac kept the original ticket numbers and this caused the issue counter to be 966, even if the total number of issues in the repo is 332 (number of PRs is 0): ``` MariaDB [gitea]> select max(`index`), count(*) from issue where repo_id=5; +--------------+----------+ | max(`index`) | count(*) | +--------------+----------+ | 966 | 332 | +--------------+----------+ ``` Trac's multiple repository support is just a bad hack, and it shares the issue counter for all the issues across all the repositories. I'm afraid the only solution is to manually renumber the issues so that their indexes are consecutive. Feel free to close this, but if you have any suggestion I'll be glad to hear it. Thank you
GiteaMirror commented 2025-11-02 05:08:05 -06:00
Author
Owner
Copy Link

@ctrlaltca commented on GitHub (May 13, 2019):

For the future me with the same problem, here's the sql i've used to fix the problem:

ALTER TABLE issue ADD COLUMN temp_id INT UNSIGNED NOT NULL;
SET @a:=0;
UPDATE issue SET temp_id=@a:=@a+1 WHERE repo_id=5 ORDER BY `created_unix` ASC;
UPDATE issue set `index` = temp_id WHERE repo_id=5;
ALTER TABLE issue DROP COLUMN temp_id;

Its needs to be run for each repository with the problem.

@ctrlaltca commented on GitHub (May 13, 2019): For the future me with the same problem, here's the sql i've used to fix the problem: ```sql ALTER TABLE issue ADD COLUMN temp_id INT UNSIGNED NOT NULL; SET @a:=0; UPDATE issue SET temp_id=@a:=@a+1 WHERE repo_id=5 ORDER BY `created_unix` ASC; UPDATE issue set `index` = temp_id WHERE repo_id=5; ALTER TABLE issue DROP COLUMN temp_id; ``` Its needs to be run for each repository with the problem.
GiteaMirror commented 2025-11-02 05:08:06 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (May 14, 2019):

That maybe a bug. When both two people are writing an issue and submit them, one will succeed and another will fail.

@lunny commented on GitHub (May 14, 2019): That maybe a bug. When both two people are writing an issue and submit them, one will succeed and another will fail.
GiteaMirror commented 2025-11-02 05:08:06 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 14, 2019):

@ctrlaltca so this is a trac import issue only?

Could you change the title to state that if so.

Did we provide the trac import script? Or where did you get the trac import script?

@zeripath commented on GitHub (May 14, 2019): @ctrlaltca so this is a trac import issue only? Could you change the title to state that if so. Did we provide the trac import script? Or where did you get the trac import script?
GiteaMirror commented 2025-11-02 05:08:06 -06:00
Author
Owner
Copy Link

@ctrlaltca commented on GitHub (May 14, 2019):

That maybe a bug. When both two people are writing an issue and submit them, one will succeed and another will fail.

I don't know the inner working of the threading model of go, but it looks like a race condition is possible.

Could you change the title to state that if so.

Done

Did we provide the trac import script? Or where did you get the trac import script?

No, it was not provided by Gitea. I just dumped the trac issue pages, regexp-extracted the data and used some sql queries to populate the tables.
Of course this is my fault for not providing a valid index for issues, so again feel free to close it.

@ctrlaltca commented on GitHub (May 14, 2019): > That maybe a bug. When both two people are writing an issue and submit them, one will succeed and another will fail. I don't know the inner working of the threading model of go, but it looks like a race condition is possible. > Could you change the title to state that if so. Done > Did we provide the trac import script? Or where did you get the trac import script? No, it was not provided by Gitea. I just dumped the trac issue pages, regexp-extracted the data and used some sql queries to populate the tables. Of course this is my fault for not providing a valid index for issues, so again feel free to close it.
GiteaMirror commented 2025-11-02 05:08:07 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 14, 2019):

Ok, although I suspect that we may have upsert issues - this wasn't caused by that. Therefore I'll close this issue as it wasn't due to Gitea. It should still be findable by anyone else who migrates from trac.

@zeripath commented on GitHub (May 14, 2019): Ok, although I suspect that we may have upsert issues - this wasn't caused by that. Therefore I'll close this issue as it wasn't due to Gitea. It should still be findable by anyone else who migrates from trac.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3320
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?