For specific repos, every sync emitted Gitea "released" activity events for every release — pure activity-feed spam with no actual release changes. Only ~2 of the reporter's ~150 repos were affected.
Root cause
The release sync contained a needsRecreation heuristic (from #148) that compared the expected order (GitHub published_at) against the order Gitea returns. For mirror repos Gitea orders releases by tag commit date, which can permanently disagree with publish order when an automated release pipeline decouples tagging from publishing. Proven inversion in chenasraf/unaconfig_dart: v0.1.0 was tagged before v0.1.1 but published after it. For such repos the check fired on every sync, deleting ALL releases and re-creating them — each re-creation emitting a fresh Gitea activity event.
Fix
Reconcile releases by set membership, not display order: create releases missing from Gitea, skip/patch existing ones, and never delete based on perceived ordering. The recreation machinery and its 1-second-per-release ordering delay are removed; the releaseLimit retention cleanup is untouched. Cosmetic display order in Gitea is not worth destroying and re-emitting releases.
Testing
10 new unit tests including the unaconfig_dart publish-vs-tag-date inversion as the regression fixture. Full suite green.
Live verification on a Gitea 1.24 test bed against the real chenasraf/unaconfig_dart: release snapshots (ids + timestamps) byte-identical across two consecutive syncs, zero delete/recreate log lines (v3.17.1 reproducibly deleted and recreated all 8 releases on every sync on the same bed).
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/RayLabsHQ/gitea-mirror/pull/318
**Author:** [@arunavo4](https://github.com/arunavo4)
**Created:** 6/12/2026
**Status:** ✅ Merged
**Merged:** 6/13/2026
**Merged by:** [@arunavo4](https://github.com/arunavo4)
**Base:** `main` ← **Head:** `fix/310-release-recreation`
---
### 📝 Commits (1)
- [`9c5dfe0`](https://github.com/RayLabsHQ/gitea-mirror/commit/9c5dfe02a7a7e7f56d8a0ae0f52ac2d9cfa15c5f) fix(releases): stop delete/recreate cycle on permanent order mismatch (#310)
### 📊 Changes
**2 files changed** (+186 additions, -99 deletions)
<details>
<summary>View changed files</summary>
➕ `src/lib/gitea-releases.test.ts` (+150 -0)
📝 `src/lib/gitea.ts` (+36 -99)
</details>
### 📄 Description
Fixes #310.
## Problem
For specific repos, every sync emitted Gitea "released" activity events for every release — pure activity-feed spam with no actual release changes. Only ~2 of the reporter's ~150 repos were affected.
## Root cause
The release sync contained a `needsRecreation` heuristic (from #148) that compared the expected order (GitHub `published_at`) against the order Gitea returns. For mirror repos Gitea orders releases by **tag commit date**, which can permanently disagree with publish order when an automated release pipeline decouples tagging from publishing. Proven inversion in `chenasraf/unaconfig_dart`: v0.1.0 was tagged before v0.1.1 but published after it. For such repos the check fired on every sync, deleting ALL releases and re-creating them — each re-creation emitting a fresh Gitea activity event.
## Fix
Reconcile releases by **set membership**, not display order: create releases missing from Gitea, skip/patch existing ones, and never delete based on perceived ordering. The recreation machinery and its 1-second-per-release ordering delay are removed; the `releaseLimit` retention cleanup is untouched. Cosmetic display order in Gitea is not worth destroying and re-emitting releases.
## Testing
- 10 new unit tests including the unaconfig_dart publish-vs-tag-date inversion as the regression fixture. Full suite green.
- Live verification on a Gitea 1.24 test bed against the real `chenasraf/unaconfig_dart`: release snapshots (ids + timestamps) byte-identical across two consecutive syncs, zero delete/recreate log lines (v3.17.1 reproducibly deleted and recreated all 8 releases on every sync on the same bed).
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/RayLabsHQ/gitea-mirror/pull/318
Author: @arunavo4
Created: 6/12/2026
Status: ✅ Merged
Merged: 6/13/2026
Merged by: @arunavo4
Base:
main← Head:fix/310-release-recreation📝 Commits (1)
9c5dfe0fix(releases): stop delete/recreate cycle on permanent order mismatch (#310)📊 Changes
2 files changed (+186 additions, -99 deletions)
View changed files
➕
src/lib/gitea-releases.test.ts(+150 -0)📝
src/lib/gitea.ts(+36 -99)📄 Description
Fixes #310.
Problem
For specific repos, every sync emitted Gitea "released" activity events for every release — pure activity-feed spam with no actual release changes. Only ~2 of the reporter's ~150 repos were affected.
Root cause
The release sync contained a
needsRecreationheuristic (from #148) that compared the expected order (GitHubpublished_at) against the order Gitea returns. For mirror repos Gitea orders releases by tag commit date, which can permanently disagree with publish order when an automated release pipeline decouples tagging from publishing. Proven inversion inchenasraf/unaconfig_dart: v0.1.0 was tagged before v0.1.1 but published after it. For such repos the check fired on every sync, deleting ALL releases and re-creating them — each re-creation emitting a fresh Gitea activity event.Fix
Reconcile releases by set membership, not display order: create releases missing from Gitea, skip/patch existing ones, and never delete based on perceived ordering. The recreation machinery and its 1-second-per-release ordering delay are removed; the
releaseLimitretention cleanup is untouched. Cosmetic display order in Gitea is not worth destroying and re-emitting releases.Testing
chenasraf/unaconfig_dart: release snapshots (ids + timestamps) byte-identical across two consecutive syncs, zero delete/recreate log lines (v3.17.1 reproducibly deleted and recreated all 8 releases on every sync on the same bed).🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.