Falco
Septembre 3, 2026, 4:55
20
@Ed_S Je pense avoir trouvé le problème et j’ai créé une PR à ce sujet. Pourrais-tu vérifier si elle concerne la zone où tu as constaté des problèmes ?
main ← new-features-no-git-in-requests
merged 05:13PM - 03 Sep 26 UTC
Previously, `CurrentUserSerializer#has_unseen_features` could derive the newest … new-feature timestamp inline, which filters the feed through `GitUtils.has_commit?` — and since we deploy from a partial clone (`--filter=tree:0`), `git merge-base --is-ancestor` on a commit missing from the local graph is lazily fetched from the promisor remote, i.e. a blocking, untimed network call to GitHub, once per feed entry, in a request. Compounding it, a fully-filtered feed cached no result at all, so every logged-in page render redid the whole loop until the worker timed out.
This change runs that check with `GIT_NO_LAZY_FETCH=1` under a hard timeout so it stays local and bounded, memoizes it per process, and makes `DiscourseUpdates.latest_new_feature_created_at` a plain Redis read derived on write (`update_new_features`, plus a throttled `Jobs::RefreshLatestNewFeature` to self-heal after a deploy or an upcoming change changing status).