[Fix] Account Linking UpdateMigrationsByType

[Sumit189]

Changes

• Added parsing check externalUserId in the UpdateMigrationsByType function. If parsing fails, subsequent function calls are skipped.

Related to: #31427

[wxiaoguang]

Sorry but IMO it is not likely a complete fix.

When using Google OAuth, the UserID returned can be quite large, such as 1108672xxx5299468800.

IIRC, when using OAuth, the "UserID" can be any string, it doesn't need to be a number.

So the root problem is that OAuth UserID shouldn't be used as original_author_id directly.

[wxiaoguang]

I would suggest to do this, either:

• simple fix: add a ParseInt64 check in UpdateMigrationsByType, if the parsing fails, do not call these functions, and leave a comment.
• complete fix: change "original_author_id" type to string and refactor all related code.

[wxiaoguang]

Thank you for trying the "complete" fix, but it would be very complex and difficult.

The problem is that "original_author_id" is indexed, if it is a varchar, then original_author_id=0 (in existing SQLs) won't be able to use the index, then all related queries become full-table scan, which will introduce performance regression. That's what I meant "refactor all related code" above.

Hmm, I see the related code, will review again.

---

To fix the problem quickly, I think the "simple fix" could be good enough, only a few lines.

[Sumit189]

Thank you for trying the "complete" fix, but it would be very complex and difficult.

The problem is that "original_author_id" is indexed, if it is a varchar, then original_author_id=0 (in existing SQLs) won't be able to use the index, then all related queries become full-table scan, which will introduce performance regression. That's what I meant "refactor all related code" above.

Hmm, I see the related code, will review again.

To fix the problem quickly, I think the "simple fix" could be good enough, only a few lines.

I had tried adding ParseInt64 check but it didn't solve the purpose.

need to make changes to a few more places will push after testing those

[wxiaoguang]

need to make changes to a few more places will push after testing those

I checkout the code, and I can see that there are still a lot of "OriginalAuthorID int64" in code ..... it is really a hard task ....

To make it consistency, we should also make the default value to empty string '' but not '0', more work ....

---

I had tried adding ParseInt64 check but it didn't solve the purpose.

Why it doesn't resolve?

I guess this should work?

// UpdateMigrationsByType updates all migrated repositories' posterid from gitServiceType to replace originalAuthorID to posterID
func UpdateMigrationsByType(ctx context.Context, tp structs.GitServiceType, externalUserID string, userID int64) error {
	if _, err := strconv.ParseInt(externalUserID, 10, 64); err != nil {
		return nil
	}

[Sumit189]

need to make changes to a few more places will push after testing those

I checkout the code, and I can see that there are still a lot of "OriginalAuthorID int64" in code ..... it is really a hard task ....

To make it consistency, we should also make the default value to empty string '' but not '0', more work ....

I had tried adding ParseInt64 check but it didn't solve the purpose.

Why it doesn't resolve?

I guess this should work?

// UpdateMigrationsByType updates all migrated repositories' posterid from gitServiceType to replace originalAuthorID to posterID
func UpdateMigrationsByType(ctx context.Context, tp structs.GitServiceType, externalUserID string, userID int64) error {
	if _, err := strconv.ParseInt(externalUserID, 10, 64); err != nil {
		return nil
	}

Yes this should work, but it will prevent update operations from being performed, this is also an issue right

will try to update all relevant code for utilizing string

[wxiaoguang]

Yes this should work, but it will prevent update operations from being performed, this is also an issue right

We could just leave a comment: // for non-numeric strings, no need to update, I think it is right to ignore these non-numeric external IDs.

will try to update all relevant code for utilizing string

It would take a lot of time, if you really would like to try (and thank you for the brave!), the migration should refer to something like v286.go and have some tests because there are so many databases and they behave differently.

[wxiaoguang]

ps: (the last suggestion for the "choice" 😁 ) I would still suggest to have a quick/simple fix first since it is right to ignore non-numeric external IDs for the "update migration type" .... the complete fix indeed seems good but it is really difficult to implement&review ..... if it introduces regressions then it would need more time to follow up ....

[Sumit189]

ps: (the last suggestion for the "choice" 😁 ) I would still suggest to have a quick/simple fix first since it is right to ignore non-numeric external IDs for the "update migration type" .... the complete fix indeed seems good but it is really difficult to implement&review ..... if it introduces regressions then it would need more time to follow up ....

lets go with simple fix for now, have reverted other code