Data too long for column 'commit_sha' at row 1

[leo-unglaub]

• Gitea version (or commit ref): 1.13.1
• Git version:2.30.0
• Operating system: OpenBSD, used from ports
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No

Description

When importing a database backup i get the following error message:

Data too long for column 'commit_sha' at row 1

The backup was generated on the same gitea version using the following command converting it from sqlite to mysql:

gitea dump --database mysql -c app.ini

At the time of the issue the table looked like this:

CREATE TABLE `comment` (
	`id` BIGINT(20) NOT NULL AUTO_INCREMENT,
	`type` INT(11) NULL DEFAULT NULL,
	`poster_id` BIGINT(20) NULL DEFAULT NULL,
	`original_author` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`original_author_id` BIGINT(20) NULL DEFAULT NULL,
	`issue_id` BIGINT(20) NULL DEFAULT NULL,
	`label_id` BIGINT(20) NULL DEFAULT NULL,
	`old_project_id` BIGINT(20) NULL DEFAULT NULL,
	`project_id` BIGINT(20) NULL DEFAULT NULL,
	`old_milestone_id` BIGINT(20) NULL DEFAULT NULL,
	`milestone_id` BIGINT(20) NULL DEFAULT NULL,
	`assignee_id` BIGINT(20) NULL DEFAULT NULL,
	`removed_assignee` TINYINT(1) NULL DEFAULT NULL,
	`assignee_team_id` BIGINT(20) NOT NULL DEFAULT '0',
	`resolve_doer_id` BIGINT(20) NULL DEFAULT NULL,
	`old_title` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`new_title` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`old_ref` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`new_ref` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`dependent_issue_id` BIGINT(20) NULL DEFAULT NULL,
	`commit_id` BIGINT(20) NULL DEFAULT NULL,
	`line` BIGINT(20) NULL DEFAULT NULL,
	`tree_path` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`content` TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`patch` TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`created_unix` BIGINT(20) NULL DEFAULT NULL,
	`updated_unix` BIGINT(20) NULL DEFAULT NULL,
	`commit_sha` VARCHAR(40) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
	`review_id` BIGINT(20) NULL DEFAULT NULL,
	`invalidated` TINYINT(1) NULL DEFAULT NULL,
	`ref_repo_id` BIGINT(20) NULL DEFAULT NULL,
	`ref_issue_id` BIGINT(20) NULL DEFAULT NULL,
	`ref_comment_id` BIGINT(20) NULL DEFAULT NULL,
	`ref_action` SMALLINT(6) NULL DEFAULT NULL,
	`ref_is_pull` TINYINT(1) NULL DEFAULT NULL,
	PRIMARY KEY (`id`) USING BTREE,
	INDEX `IDX_comment_issue_id` (`issue_id`) USING BTREE,
	INDEX `IDX_comment_created_unix` (`created_unix`) USING BTREE,
	INDEX `IDX_comment_updated_unix` (`updated_unix`) USING BTREE,
	INDEX `IDX_comment_ref_repo_id` (`ref_repo_id`) USING BTREE,
	INDEX `IDX_comment_type` (`type`) USING BTREE,
	INDEX `IDX_comment_review_id` (`review_id`) USING BTREE,
	INDEX `IDX_comment_ref_issue_id` (`ref_issue_id`) USING BTREE,
	INDEX `IDX_comment_ref_comment_id` (`ref_comment_id`) USING BTREE,
	INDEX `IDX_comment_poster_id` (`poster_id`) USING BTREE
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=2034
;

The insert statement in question looks like this:

INSERT INTO `comment` (`id`, `type`, `poster_id`, `original_author`, `original_author_id`, `issue_id`, `label_id`, `old_project_id`, `project_id`, `old_milestone_id`, `milestone_id`, `assignee_id`, `removed_assignee`, `assignee_team_id`, `resolve_doer_id`, `old_title`, `new_title`, `old_ref`, `new_ref`, `dependent_issue_id`, `commit_id`, `line`, `tree_path`, `content`, `patch`, `created_unix`, `updated_unix`, `commit_sha`, `review_id`, `invalidated`, `ref_repo_id`, `ref_issue_id`, `ref_comment_id`, `ref_action`, `ref_is_pull`) VALUES (1758,11,25,'',0,530,0,NULL,NULL,0,0,0,false,0,NULL,'','','','',0,0,0,'','','',1591220008,1591220008,'feature/get-unit-and-store-it-in-the-database-version-2',0,false,0,0,0,0,false);

I am not sure why this column contains something that looks like a description instead of a hash, but thats what it tries to do. The system running on sqlite was always used as intended and never manupilated or anything else.

[lunny]

commit_sha was designered to store Git commit hash. hm

[leo-unglaub]

Thats what i would have guessed as well. The only thing i noticed is that this always happens in rows where content = ''. Maybe this has something todo with it. The content in the commit_sha seams to be the name of the pull request that got mentioned in the text.

[leo-unglaub]

Maybe this is helpful or a hint on whats going on.

[jpraet]

The comment for deleting a branch stores the branch name instead of commit_sha:

gitea/models/issue.go

Lines 747 to 753 in d3aa497

	var opts = &CreateCommentOptions{
	Type: CommentTypeDeleteBranch,
	Doer: doer,
	Repo: repo,
	Issue: issue,
	CommitSHA: branchName,
	}

[zeripath]

@jpraet that looks like it would be the cause.

Ok I guess the question is where should the branch name be stored...

[richmahn]

@lunny You removed the back port label from the PR, but will this issue be back ported? Still shows the label here.

[zeripath]

The issue is the migration really. Could make a doctor command to fix it?

[zeripath]

OK if we were to attempt to backport this we'd have to adjust the v169.go migration to only run if the commit_sha != '' otherwise any fixed delete branch comments would get overridden.

So that would mean an additional PR to fix this along with additional doctor commands and or clever template manipulation to make things work.

[6543]

I think this in any case require a manual step, so backport will be breaking regardles what we do

manipulating template would only break custom templates so if we realy want to backport, we should add more logic to the template

[zeripath]

we'd still need a PR on to master to change the migration.

[6543]

didn't we already have it in #14604 ?!?

the "UPDATE comment SET old_ref = commit_sha, commit_sha = '' WHERE type = 11" ?

[zeripath]

that would need to become

"UPDATE comment SET old_ref = commit_sha, commit_sha = '' WHERE type = 11 AND commit_sha != ''"

[6543]

yes if we really going to backport it ...