Latest commits for branch codeberg-13

CB/feat: ToU announcement

Gusted — Mon, 22 Dec 2025 01:48:31 +0100

CB/feat: ToU announcement Usable for nosJS environment (no way to hide it). Do not show it by default to avoid it briefly showing and shifting the layout when the announcement is dismissed. A dummy `

` is used as first child that has the same width of the button so the text is correctly centered (we can't use `position: absolute` that will overlap with the text at certain screen widths).

CB/fix: reduce granulity of last used columns

Gusted — Mon, 22 Dec 2025 01:48:31 +0100

CB/fix: reduce granulity of last used columns These create many `UPDATE` queries, reduce the granulity to a minute.

CB/bp: fix: garbage collect lingering actions logs (#10009)

Earl Warren — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: fix: garbage collect lingering actions logs (#10009) If, for any reason (e.g. server crash), a task is recorded as done in the database but the logs are still in the database instead of being in storage, they need to be collected. The log_in_storage field is only set to true after the logs have been transfered to storage and can be relied upon to reflect which tasks have lingering logs. A cron job collects lingering logs every day, 3000 at a time, sleeping one second between them. In normal circumstances there will be only a few of them, even on a large instance, and there is no need to collect them as quickly as possible. When there are a lot of them for some reason, garbage collection must happen at a rate that is not too hard on storage I/O. Refs https://codeberg.org/forgejo/forgejo/issues/9999 Co-authored-by: Mathieu Fenniak Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10009 Reviewed-by: Mathieu Fenniak Reviewed-by: Gusted Co-authored-by: Earl Warren Co-committed-by: Earl Warren --- Codeberg modification: Bump the values so it doesn't take a year to transfer lingering action logs.

CB/bp: fix: readjust indexes on the 'action' table

Mathieu Fenniak — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: fix: readjust indexes on the 'action' table Ref: forgejo/forgejo!10040 Codeberg modification: migration dropped, is manually created.

CB/bp: chore: Remove IsDeleted from action (activity) table

Leni Kadali — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: chore: Remove IsDeleted from action (activity) table Fixes https://codeberg.org/forgejo/forgejo/issues/3525 and supersedes https://codeberg.org/forgejo/forgejo/pulls/9586 Co-authored-by: Mathieu Fenniak Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9829 Reviewed-by: Mathieu Fenniak Co-authored-by: Leni Kadali Co-committed-by: Leni Kadali

CB/bp: fix: possible cause of invalid issue counts; cache invalidation occurs before a active transaction is committed (#10130)

Mathieu Fenniak — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: fix: possible cause of invalid issue counts; cache invalidation occurs before a active transaction is committed (#10130) Although #9922 was deployed to Codeberg, it was reported on Matrix that a user observed a `-1` pull request count. @Gusted checked and verified that the stats stored in redis appeared incorrect, and that no errors occurred on Codeberg that included the repo ID (eg. deadlocks, SQL queries). ``` 127.0.0.1:6379> GET Repo:CountPulls:924266 "1" 127.0.0.1:6379> GET Repo:CountPullsClosed:924266 "2" ``` One possible cause is that when `UpdateRepoIssueNumbers` is invoked and invalidates the cache key for the repository, it is currently in a transaction; the next request for that cached count could be computed before the transaction is committed and the update is visible. It's been verified that `UpdateRepoIssueNumbers` is called within a transaction in most interactions (I put a panic in it if `db.InTransaction(ctx)`, and most related tests failed). This PR fixes that hole by performing the cache invalidation in an `AfterTx()` hook which is invoked after the transaction is committed to the database. (Another possible cause is documented in #10127) Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10130 Reviewed-by: Gusted Co-authored-by: Mathieu Fenniak Co-committed-by: Mathieu Fenniak

CB/bp: fix: reduce deadlocks merging PRs w/ async milestone stat recalcs (#9916)

Mathieu Fenniak — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: fix: reduce deadlocks merging PRs w/ async milestone stat recalcs (#9916) Continuing the pattern from #9868, fixes another deadlock discovered in synthetic testing of #9785. This modifies the `milestone` table to have the `num_issues`, `num_closed_issues`, and `completeness` statistics be calculated asynchronously. An optional `updateTimestamp` field was added to the stats queue to support the conditional updating of the milestone's modification date, retaining existing functionality. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9916 Reviewed-by: Earl Warren Co-authored-by: Mathieu Fenniak Co-committed-by: Mathieu Fenniak

CB/bp: fix: reduce deadlocks merging PRs w/ async label stat recalcs (#9868)

Mathieu Fenniak — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: fix: reduce deadlocks merging PRs w/ async label stat recalcs (#9868) The intent of this change is to reduce the scope of deadlock issues identified in #9785. I've identified other deadlock issues from synthetic testing, so this is not a complete fix, but it's a partial fix. This design was discussed in #9785 and this is the most basic implementation, with a very small scope of work converted to use it. Introduces a new `forgejo.org/services/stats` module which allows for the queuing and routing of recalc requests for object stats; in this case, the "number of issues" that are assigned to a label, and the number of closed issues that are assigned to a label. The reasons that these calculations are performed asynchronously through a queue are: - User operations that are common and performance-sensitive don't have to wait for recalculations that don't need to be exactly up-to-date at all times. For example, merging a pull request will be a faster operation; as it closes an issue, it needs to recalculate `label.num_closed_issues` for every label attached to the PR. - Database deadlocks that can occur between concurrent operations -- for example, if you were holding a lock on an issue while recalculating a label's count of open issues -- can be broken by making the recalculation occur outside of the transaction. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9868 Reviewed-by: Gusted Co-authored-by: Mathieu Fenniak Co-committed-by: Mathieu Fenniak

CB/bp: fix: possible cause of invalid issue counts; cache module doesn't guarantee concurrency safety

Mathieu Fenniak — Mon, 22 Dec 2025 01:48:31 +0100

CB/bp: fix: possible cause of invalid issue counts; cache module doesn't guarantee concurrency safety

CB/feat: better metrics

Gusted — Mon, 22 Dec 2025 01:48:31 +0100

CB/feat: better metrics Better prometheus metrics, the count of tables are not interesting and rather slow.