adam/gitea-mirror
1
0 Fork 0
mirror of https://github.com/RayLabsHQ/gitea-mirror.git synced 2026-11-04 08:12:21 +01:00
Code Issues 4 Packages Projects Releases Wiki Activity

Activity Log retains stale "syncing" count after successful repository sync #179

New Issue
Closed
opened 2026-10-05 01:46:05 +02:00 by adam · 3 comments
adam commented 2026-10-05 01:46:05 +02:00
Owner
Copy link
Copy source

Description

When using Gitea Mirror with a Gitea / Forgejo source and GitHub destination, a completed repository sync leaves a stale syncing count in the Activity Log even though the sync finishes successfully.

The repository itself is synchronized correctly. This appears to be an Activity Log / status-accounting issue rather than a Git push failure.

Environment

  • Gitea Mirror: v3.40.2
  • Deployment: Docker
  • Source: Gitea / Forgejo
  • Destination: GitHub
  • Destination mode: User Repositories
  • Repository used for reproduction: bambu-lab-filament

Steps to reproduce

  1. Configure a Gitea / Forgejo source and GitHub destination.
  2. Mirror bambu-lab-filament successfully.
  3. Clear the complete Activity History so the Activity Log contains 0 activities.
  4. Manually run Sync on bambu-lab-filament.
  5. Wait for the sync to finish.
  6. Open the Activity Log.

Actual behavior

The Activity Log shows three entries:

  • Mirror successful
    • Completed sync job with 1 items
  • Syncing in progress — bambu-lab-filament
    • Started syncing repository: bambu-lab-filament
  • Sync successful — bambu-lab-filament
    • Successfully synced repository: bambu-lab-filament

However, the Activity Log summary still reports:

3 activities
1 syncing

The repository has already finished syncing successfully.

Refreshing/reloading the page does not clear the stale 1 syncing count.

Expected behavior

After bambu-lab-filament completes syncing successfully:

  • the Activity Log summary should report 0 syncing
  • the previous Syncing in progress entry should not continue to count as an active sync
  • the completed job should be represented only as completed

Additional observations

I originally noticed similar behavior on v3.36.2.

An exported Activity Log from that version showed the same state-model inconsistency. For example, a repository start event could contain:

{
  "status": "syncing",
  "message": "Started syncing repository: traefik-primary",
  "inProgress": false
}

followed immediately by:

{
  "status": "synced",
  "message": "Successfully synced repository: traefik-primary",
  "inProgress": false
}

After upgrading to v3.40.2, I cleared all Activity History and reproduced the issue again from a clean log using bambu-lab-filament.

Impact

No repository data loss or synchronization failure has been observed.

The issue affects monitoring/status accuracy: the UI reports a repository as still syncing after the operation has completed successfully, making it difficult to distinguish a genuinely stuck sync from stale Activity Log state.

Screenshot

Attached screenshot shows:

  • Mirror successful
  • Syncing in progress for bambu-lab-filament
  • Sync successful for bambu-lab-filament
  • Activity Log summary still showing 1 syncing
Image
## Description When using Gitea Mirror with a **Gitea / Forgejo source** and **GitHub destination**, a completed repository sync leaves a stale `syncing` count in the Activity Log even though the sync finishes successfully. The repository itself is synchronized correctly. This appears to be an Activity Log / status-accounting issue rather than a Git push failure. ## Environment - Gitea Mirror: v3.40.2 - Deployment: Docker - Source: Gitea / Forgejo - Destination: GitHub - Destination mode: User Repositories - Repository used for reproduction: `bambu-lab-filament` ## Steps to reproduce 1. Configure a Gitea / Forgejo source and GitHub destination. 2. Mirror `bambu-lab-filament` successfully. 3. Clear the complete Activity History so the Activity Log contains `0 activities`. 4. Manually run `Sync` on `bambu-lab-filament`. 5. Wait for the sync to finish. 6. Open the Activity Log. ## Actual behavior The Activity Log shows three entries: - `Mirror successful` - `Completed sync job with 1 items` - `Syncing in progress` — `bambu-lab-filament` - `Started syncing repository: bambu-lab-filament` - `Sync successful` — `bambu-lab-filament` - `Successfully synced repository: bambu-lab-filament` However, the Activity Log summary still reports: ```text 3 activities 1 syncing ``` The repository has already finished syncing successfully. Refreshing/reloading the page does not clear the stale `1 syncing` count. ## Expected behavior After `bambu-lab-filament` completes syncing successfully: - the Activity Log summary should report `0 syncing` - the previous `Syncing in progress` entry should not continue to count as an active sync - the completed job should be represented only as completed ## Additional observations I originally noticed similar behavior on v3.36.2. An exported Activity Log from that version showed the same state-model inconsistency. For example, a repository start event could contain: ```json { "status": "syncing", "message": "Started syncing repository: traefik-primary", "inProgress": false } ``` followed immediately by: ```json { "status": "synced", "message": "Successfully synced repository: traefik-primary", "inProgress": false } ``` After upgrading to v3.40.2, I cleared all Activity History and reproduced the issue again from a clean log using `bambu-lab-filament`. ## Impact No repository data loss or synchronization failure has been observed. The issue affects monitoring/status accuracy: the UI reports a repository as still syncing after the operation has completed successfully, making it difficult to distinguish a genuinely stuck sync from stale Activity Log state. ## Screenshot Attached screenshot shows: - `Mirror successful` - `Syncing in progress` for `bambu-lab-filament` - `Sync successful` for `bambu-lab-filament` - Activity Log summary still showing `1 syncing` <img width="1836" height="477" alt="Image" src="https://github.com/user-attachments/assets/47dc7c3b-7f6f-430b-b060-430c17059ec4" /> <!-- github-sync-id:5590153709 -->
adam closed this issue 2026-10-05 01:46:05 +02:00
adam commented 2026-10-05 01:46:06 +02:00
Author
Owner
Copy link
Copy source

Added a sanitized JSON export of the activity shown in the screenshot.

activity_log_export_2026-09-26(1).json

Added a sanitized JSON export of the activity shown in the screenshot. [activity_log_export_2026-09-26(1).json](https://github.com/user-attachments/files/32674002/activity_log_export_2026-09-26.1.json) <!-- github-comment-id:5841743895 -->
adam commented 2026-10-05 01:46:07 +02:00
Author
Owner
Copy link
Copy source

Additional finding: scheduled sync does not reproduce the stale syncing count

I have another data point that appears to narrow this issue.

At 9:00 PM, the normal hourly scheduler ran against all 13 mirrored repositories.

The scheduled run produced:

  • 13 syncing activity events
  • 13 corresponding synced activity events
  • Activity Log summary correctly showing 13 synced
  • No stale syncing count remained in the UI

For example, repositories all received a syncing event followed by a successful synced event.

One repository also updated 1 ref successfully during the scheduled run, so this was not purely a no-op sync.

Comparison with the failing manual sync

The earlier manual single-repository Sync against bambu-lab-filament reproduced the issue:

  • Syncing in progress
  • Sync successful
  • Completed sync job with 1 items
  • Activity Log summary still showed 1 syncing

The manual run also created an additional aggregate activity record:

{
  "status": "mirrored",
  "message": "Completed sync job with 1 items",
  "jobType": "sync",
  "totalItems": 1,
  "completedItems": 1,
  "inProgress": false
}

<!-- github-comment-id:5841801118 -->
## Additional finding: scheduled sync does not reproduce the stale `syncing` count I have another data point that appears to narrow this issue. At **9:00 PM**, the normal hourly scheduler ran against all 13 mirrored repositories. The scheduled run produced: - 13 `syncing` activity events - 13 corresponding `synced` activity events - Activity Log summary correctly showing `13 synced` - No stale `syncing` count remained in the UI For example, repositories all received a `syncing` event followed by a successful `synced` event. One repository also updated 1 ref successfully during the scheduled run, so this was not purely a no-op sync. ## Comparison with the failing manual sync The earlier **manual single-repository Sync** against `bambu-lab-filament` reproduced the issue: - `Syncing in progress` - `Sync successful` - `Completed sync job with 1 items` - Activity Log summary still showed `1 syncing` The manual run also created an additional aggregate activity record: ```json { "status": "mirrored", "message": "Completed sync job with 1 items", "jobType": "sync", "totalItems": 1, "completedItems": 1, "inProgress": false } <!-- github-comment-id:5841801118 -->
adam commented 2026-10-05 01:46:07 +02:00
Author
Owner
Copy link
Copy source

@MERCURIALZED thanks for the export, it pointed straight at the cause. Fixed in v3.40.3: https://github.com/RayLabsHQ/gitea-mirror/releases/tag/v3.40.3

All three events from your manual sync have the same timestamp, 00:29:48. Activity times are stored to the second, and events from the same second came back oldest first. So "Started syncing" was listed ahead of "Successfully synced", and the summary took it as the repository's current state. The scheduled run spaced the two events further apart, which is why it counted correctly.

Activities now come back newest first within the same second too, and the summary counts a finish over a start from the same second. Your existing log should show the right count after upgrading, without clearing it.

The inProgress: false on the per-repository events is expected. That flag only tracks the aggregate job record, not individual repository events.

@MERCURIALZED thanks for the export, it pointed straight at the cause. Fixed in v3.40.3: https://github.com/RayLabsHQ/gitea-mirror/releases/tag/v3.40.3 All three events from your manual sync have the same timestamp, `00:29:48`. Activity times are stored to the second, and events from the same second came back oldest first. So "Started syncing" was listed ahead of "Successfully synced", and the summary took it as the repository's current state. The scheduled run spaced the two events further apart, which is why it counted correctly. Activities now come back newest first within the same second too, and the summary counts a finish over a start from the same second. Your existing log should show the right count after upgrading, without clearing it. The `inProgress: false` on the per-repository events is expected. That flag only tracks the aggregate job record, not individual repository events. <!-- github-comment-id:5842904062 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/gitea-mirror#179