<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=263508) </details> <!--IssueSummary end--> The following discussion from !44629 should be addressed: - [ ] @patrickbajao started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44629#note_425856325): (+1 comment) > Can we open a follow-up issue and add a link here? :slight_smile: > > Also I'm wondering, why do we need to force re-caching? https://gitlab.com/gitlab-org/gitlab/-/issues/254823#note_424776902 > one thing we need to keep in mind here, without doing anything fancy, enabling *either* of these approaches would only impact **new** diffs, and I worry we'll see an issue with the caching akin to what we spotted when lifting the diff size limit (IE - since we don't pass the diff contents on to the cache when the diff is `collapsed`, we'll only have `[]` in the cache without doing some extra steps. Extra complexity in this project will involve figuring out what needs doing there, specifically.) Additionally, when working with increasing the diff size limit for individual files, we saw a similar issue where we would decide a file could be "expanded" but the existing cache had `[]` results. (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43778) In this case, we also could've used a "force refresh the cache" options.