Gitea shows outdated commit status with distributed DB backend (eg. TiDB) #30074
Labels
Comments
lunny
pushed a commit
that referenced
this issue
Mar 28, 2024
…30076) This PR replaces the use of `max( id )`, and instead using ``max( `index` )`` for determining the latest commit status. Building business logic over an `auto_increment` primary key like `id` is risky and there’re already plenty of discussions on the Internet. There‘s no guarantee for `auto_increment` values to be monotonic, especially upon failures or with a cluster. In the specific case, we met the problem of commit statuses being outdated when using TiDB as the database. As [being documented](https://docs.pingcap.com/tidb/stable/auto-increment), `auto_increment` values assigned to an `insert` statement will only be monotonic on a per server (node) basis. Closes #30074.
stevapple
added a commit
to stevapple/gitea
that referenced
this issue
Mar 28, 2024
…o-gitea#30076) This PR replaces the use of `max( id )`, and instead using ``max( `index` )`` for determining the latest commit status. Building business logic over an `auto_increment` primary key like `id` is risky and there’re already plenty of discussions on the Internet. There‘s no guarantee for `auto_increment` values to be monotonic, especially upon failures or with a cluster. In the specific case, we met the problem of commit statuses being outdated when using TiDB as the database. As [being documented](https://docs.pingcap.com/tidb/stable/auto-increment), `auto_increment` values assigned to an `insert` statement will only be monotonic on a per server (node) basis. Closes go-gitea#30074.
silverwind
pushed a commit
that referenced
this issue
Mar 28, 2024
…30076) (#30155) Backport #30076. This PR replaces the use of `max( id )`, and instead using ``max( `index` )`` for determining the latest commit status. Building business logic over an `auto_increment` primary key like `id` is risky and there’re already plenty of discussions on the Internet. There‘s no guarantee for `auto_increment` values to be monotonic, especially upon failures or with a cluster. In the specific case, we met the problem of commit statuses being outdated when using TiDB as the database. As [being documented](https://docs.pingcap.com/tidb/stable/auto-increment), `auto_increment` values assigned to an `insert` statement will only be monotonic on a per server (node) basis. Closes #30074.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Gitea doesn’t always show the latest commit status (i.e. being outdated) if you use some distributed database as backend. An
auto_incrementprimary key, though being expected to bump at a step of 1 at everyINSERT, may be designed to bump independently on each nodes.We should update
commit_status.goto use the(max(`index`), repo_id, sha)triple to determine the latest commit status, instead of relying onmax(id).Gitea Version
1.21.9
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
I’m running Gitea on a Kubernetes cluster, which also hosts Woodpecker CI v2.3.0 and TiDB v7.5.1. Gitea uses TiDB (through
mysql) as backend and Woodpecker uses Gitea as forge.The problem was originally identified as “randomly dropping commit status on either Woodpecker, Gitea and TiDB side”, but after digging into the database it turns out that all commit statuses were there.
Database
MySQL/MariaDB
The text was updated successfully, but these errors were encountered: