Repository statistics cache remains stale after force‑push in Forgejo ≥1.20

Direct Answer

Yes, the cache should be invalidated automatically on push operations that rewrite history (force-pushes). A pure time-based TTL cannot distinguish a force-push from normal aging, so event-driven invalidation is the correct primary mechanism with TTL serving only as a safety net.

Why Statistics Go Stale

Forgejo inherits Gitea's architecture where repository statistics (commit count on the default branch, repository size, branch count) are computed by background maintenance tasks and stored. Push hooks update refs and trigger post-receive processing, but the expensive statistics recomputation is deliberately decoupled from the push path to keep push latency low. Consequently, nothing recalculates commit counts after a history rewrite unless an admin runs forgejo admin repo-reindex (or the version-equivalent command) or a periodic background job executes.

Recommended Hybrid Approach

1. Event-driven enqueue on push: In the post-receive hook, detect a non-fast-forward update (force-push) by comparing old and new revision SHAs. When detected, enqueue a single asynchronous statistics-refresh job for that repository.
2. Debounce and deduplicate: Coalesce multiple push events within a configurable window (e.g., 30–120 seconds) into one job per repository. This prevents a burst of pushes from triggering repeated recomputation.
3. Fallback TTL: Keep a moderate TTL of 15–60 minutes as a safety net for any missed events or manual ref edits outside the push path.
4. Optimize fast-forward pushes: For regular (fast-forward) pushes, adjust the cached commit count by the ahead/behind delta instead of a full recount. Reserve full recomputation for force-pushes where history actually changed.

Configurability

Expose an admin toggle (e.g., [repository] REFRESH_STATS_ON_PUSH = true) and a debounce interval setting in app.ini. Small instances can enable immediate freshness; large hosting providers can disable or lengthen the debounce to bound database load. This mirrors how other Forgejo/Gitea maintenance tasks are already configurable.

One Missing Diagnostic Detail

What exact Forgejo version is deployed, and what does its app.ini show for existing statistics-related cron/task settings (e.g., cron.update_mirror intervals, task.repository_stats_update or similar)? The 30-minute TTL and admin repo-reindex command name in the prompt vary by release; verifying the installed version's actual cache implementation and CLI nomenclature is required before implementing any invalidation logic.

Verification Steps

1. Force-push a rewritten branch to a test repository.
2. Record the commit count shown in the UI immediately after the push.
3. Run the admin statistics/reindex task for that repository.
4. Compare the before/after values to confirm the cache was the stale component.
5. Enable debug logging or inspect the task queue during a push to verify whether any stats-refresh task is already enqueued on push events in your version.

Cautions

• Synchronous recomputation inside the push path will noticeably slow pushes on large repositories—always offload to a background queue.
• A naive invalidate-on-every-push policy can be abused; debouncing and per-repository job deduplication are essential.
• Size statistics may drift due to git gc/aggressive packing timing, so even event-driven refresh can show size changes unrelated to pushes.