github-starred/gitea-mirror
2
0
Fork 0
mirror of https://github.com/RayLabsHQ/gitea-mirror.git synced 2026-07-18 19:26:26 -05:00
Code Issues 323 Packages Projects Releases 113 Wiki Activity

[PR #300] [MERGED] fix: stop snapshot-row zombies + flapping force-push on deleted branches #6593

New Issue
Closed
opened 2026-07-13 13:13:10 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-07-13 13:13:10 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/RayLabsHQ/gitea-mirror/pull/300
Author: @seanmousseau
Created: 5/25/2026
Status: ✅ Merged
Merged: 5/26/2026
Merged by: @arunavo4

Base: main ← Head: fix/snapshot-row-status-and-deleted-branch-flapping

📝 Commits (2)

  • 093b958 fix: stop snapshot-row zombies + flapping force-push on deleted branches
  • c2dfbaa fix: acknowledge deletion before backup, not after, to fix concurrent-sync race

📊 Changes

4 files changed (+297 additions, -4 deletions)

View changed files

📝 src/lib/gitea-enhanced.ts (+57 -3)
📝 src/lib/metadata-state.ts (+28 -0)
📝 src/lib/utils/force-push-detection.test.ts (+185 -0)
📝 src/lib/utils/force-push-detection.ts (+27 -1)

📄 Description

Summary

Two bugs caused production gitea-mirror to accumulate one orphan "Snapshot created" job row per scheduled sync — 7 zombies in 24h on Simple-WP-Helpdesk against a deleted GitHub branch (fix/v4.0.2-webhook-comment-author).

Bug 1: snapshot job row stuck in non-terminal status

gitea-enhanced.ts created the post-snapshot mirror_jobs record with status: \"syncing\". But the snapshot was already complete at that point (createPreSyncBundleBackup returned successfully), and no later code path advanced the row to a terminal status. Each force-push-triggered backup leaked an orphan row. Fix: status: \"synced\".

Bug 2: force-push detection flapping on deleted branches

force-push-detection.ts treated any Gitea branch missing from GitHub as a "deleted" force-push. But gitea-mirror is one-way (GitHub → Gitea), so deletions never propagate back to the Gitea mirror — the branch lingers in Gitea forever, the missing-from-GitHub condition holds on every subsequent sync, and detection re-fires endlessly. With backupBeforeSync: true this triggered a fresh snapshot of the exact same state every cycle.

Fix: extend RepositoryMetadataState with an acknowledgedDeletions: { branch, giteaSha }[] list (persisted on the repository row). The detector accepts this list and suppresses deleted branches whose current giteaSha matches an entry. If the giteaSha later changes (branch restored, then re-deleted with new history), the entry won't match and detection fires again — back up the new state, then acknowledge the new SHA.

The acknowledge-push runs right after detection, not after backup success. The first iteration of this fix gated it on the backup try block, which broke when concurrent sync invocations both detected the deletion but only one's createPreSyncBundleBackup actually fired (the other short-circuited because the file already existed). The second invocation skipped the push, then raced its empty in-memory acknowledgedDeletions onto the metadata row, undoing the first invocation's write. Moving the push earlier makes the race benign: both invocations push the same entry, both write the same metadata.

Production validation (2026-05-25)

Built gitea-mirror:fix-snapshot-zombies-v2 from this branch, deployed via Komodo API to the production gitea-mirror instance, and ran a controlled repro:

  1. Forged a claude-test/zombie-repro ref directly in Gitea's bare repository for sean/Simple-WP-Helpdesk (branch table row + git ref) so that Gitea had a branch GitHub didn't — recreating the bug condition exactly.
  2. First sync (UI-triggered, ran two concurrent invocations):
    • Both invocations detected the deletion: 2 "Snapshot created" rows at 22:03:15 + 22:03:17, both with status=synced (Bug 1 fix verified — no zombies).
    • Both invocations pushed the entry into acknowledgedDeletions; the final metadata persisted [{branch: \"claude-test/zombie-repro\", giteaSha: \"41c76615...\"}] (Bug 2 fix verified — race-safe).
  3. Second sync (forged at the same SHA, acknowledged entry present):
    • Zero "Force-push detected" log lines (silently suppressed).
    • Zero new "Snapshot created" rows.
    • Acknowledged entry preserved in metadata.
  4. Cleanup: deleted the forged ref, marked the branch table row deleted, reset acknowledgedDeletions to [].

Test plan

  • bun test src/lib/utils/force-push-detection.test.ts — 9 new structural test cases covering: suppression when giteaSha matches; re-flag when giteaSha differs; only-acknowledged-deletion suppression in mixed cases; undefined list back-compat; diverged branches not suppressed via deletions list; metadata-state round-trip; legacy-blob defaulting; malformed-entry resilience.
  • bun test src/lib/gitea-enhanced.test.ts src/lib/repo-backup.test.ts — 59 tests pass, no regressions.
  • Production validation: concurrent-invocation repro proves both bugs are fixed end-to-end. See above.

Files

  • src/lib/gitea-enhanced.ts — status fix, hoisted metadataState, moved acknowledge-push to after detection (pre-backup) to fix race
  • src/lib/metadata-state.ts — added AcknowledgedDeletion type + parse/serialize support
  • src/lib/utils/force-push-detection.ts — accepts acknowledgedDeletions, suppresses matching entries
  • src/lib/utils/force-push-detection.test.ts — 9 new test cases

🤖 Generated with Claude Code

🔄 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/300 **Author:** [@seanmousseau](https://github.com/seanmousseau) **Created:** 5/25/2026 **Status:** ✅ Merged **Merged:** 5/26/2026 **Merged by:** [@arunavo4](https://github.com/arunavo4) **Base:** `main` ← **Head:** `fix/snapshot-row-status-and-deleted-branch-flapping` --- ### 📝 Commits (2) - [`093b958`](https://github.com/RayLabsHQ/gitea-mirror/commit/093b958acf960051030a08266e66b8d5dcd16081) fix: stop snapshot-row zombies + flapping force-push on deleted branches - [`c2dfbaa`](https://github.com/RayLabsHQ/gitea-mirror/commit/c2dfbaa306a73e9be975f94065cd3c4c877511cd) fix: acknowledge deletion before backup, not after, to fix concurrent-sync race ### 📊 Changes **4 files changed** (+297 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/lib/gitea-enhanced.ts` (+57 -3) 📝 `src/lib/metadata-state.ts` (+28 -0) 📝 `src/lib/utils/force-push-detection.test.ts` (+185 -0) 📝 `src/lib/utils/force-push-detection.ts` (+27 -1) </details> ### 📄 Description ## Summary Two bugs caused production gitea-mirror to accumulate one orphan "Snapshot created" job row per scheduled sync — 7 zombies in 24h on `Simple-WP-Helpdesk` against a deleted GitHub branch (`fix/v4.0.2-webhook-comment-author`). ### Bug 1: snapshot job row stuck in non-terminal status `gitea-enhanced.ts` created the post-snapshot `mirror_jobs` record with `status: \"syncing\"`. But the snapshot was already complete at that point (`createPreSyncBundleBackup` returned successfully), and **no later code path advanced the row to a terminal status**. Each force-push-triggered backup leaked an orphan row. Fix: `status: \"synced\"`. ### Bug 2: force-push detection flapping on deleted branches `force-push-detection.ts` treated any Gitea branch missing from GitHub as a \"deleted\" force-push. But gitea-mirror is one-way (GitHub → Gitea), so deletions never propagate back to the Gitea mirror — the branch lingers in Gitea forever, the missing-from-GitHub condition holds on every subsequent sync, and detection re-fires endlessly. With `backupBeforeSync: true` this triggered a fresh snapshot of the exact same state every cycle. Fix: extend `RepositoryMetadataState` with an `acknowledgedDeletions: { branch, giteaSha }[]` list (persisted on the repository row). The detector accepts this list and suppresses deleted branches whose current `giteaSha` matches an entry. If the `giteaSha` later changes (branch restored, then re-deleted with new history), the entry won't match and detection fires again — back up the new state, then acknowledge the new SHA. The acknowledge-push runs **right after detection**, not after backup success. The first iteration of this fix gated it on the backup `try` block, which broke when concurrent sync invocations both detected the deletion but only one's `createPreSyncBundleBackup` actually fired (the other short-circuited because the file already existed). The second invocation skipped the push, then raced its empty in-memory `acknowledgedDeletions` onto the metadata row, undoing the first invocation's write. Moving the push earlier makes the race benign: both invocations push the same entry, both write the same metadata. ## Production validation (2026-05-25) Built `gitea-mirror:fix-snapshot-zombies-v2` from this branch, deployed via Komodo API to the production gitea-mirror instance, and ran a controlled repro: 1. **Forged a `claude-test/zombie-repro` ref** directly in Gitea's bare repository for `sean/Simple-WP-Helpdesk` (branch table row + git ref) so that Gitea had a branch GitHub didn't — recreating the bug condition exactly. 2. **First sync** (UI-triggered, ran two concurrent invocations): - **Both** invocations detected the deletion: 2 \"Snapshot created\" rows at 22:03:15 + 22:03:17, both with `status=synced` (Bug 1 fix verified — no zombies). - **Both** invocations pushed the entry into `acknowledgedDeletions`; the final metadata persisted `[{branch: \"claude-test/zombie-repro\", giteaSha: \"41c76615...\"}]` (Bug 2 fix verified — race-safe). 3. **Second sync** (forged at the same SHA, acknowledged entry present): - **Zero** \"Force-push detected\" log lines (silently suppressed). - **Zero** new \"Snapshot created\" rows. - Acknowledged entry preserved in metadata. 4. Cleanup: deleted the forged ref, marked the branch table row deleted, reset `acknowledgedDeletions` to `[]`. ## Test plan - [x] `bun test src/lib/utils/force-push-detection.test.ts` — 9 new structural test cases covering: suppression when giteaSha matches; re-flag when giteaSha differs; only-acknowledged-deletion suppression in mixed cases; undefined list back-compat; diverged branches not suppressed via deletions list; metadata-state round-trip; legacy-blob defaulting; malformed-entry resilience. - [x] `bun test src/lib/gitea-enhanced.test.ts src/lib/repo-backup.test.ts` — 59 tests pass, no regressions. - [x] **Production validation**: concurrent-invocation repro proves both bugs are fixed end-to-end. See above. ## Files - `src/lib/gitea-enhanced.ts` — status fix, hoisted metadataState, moved acknowledge-push to after detection (pre-backup) to fix race - `src/lib/metadata-state.ts` — added `AcknowledgedDeletion` type + parse/serialize support - `src/lib/utils/force-push-detection.ts` — accepts `acknowledgedDeletions`, suppresses matching entries - `src/lib/utils/force-push-detection.test.ts` — 9 new test cases 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-07-13 13:13:10 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea-mirror#6593
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?