Fix for the rebase merge request state being shown incorrectly
What does this MR do and why?
This is a potential fix for #389074 (closed) in that the rebase merge request widget state gets shown incorrectly.
Previously, the following was happening:
- Merge request form gets submitted.
- User gets direct to merge request page, which loads the widget.
- The value for
ff_merge_possible?
gets cached incorrectly.
In between steps 1 and 2, the async diff creation is happening, which actually fetches the ref into the project. If the ref is fetched after the page is loaded, the widget will cache the wrong value, and the state won't expire until either the target branch SHA changes or the diff head SHA changes.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
- Create a project with some
README.md
. - In the project settings -> Merge Requests -> Set
Merge commit with semi-linear history
. - Fork this project in another namespace.
- Apply this diff:
diff --git a/app/services/merge_requests/after_create_service.rb b/app/services/merge_requests/after_create_service.rb
index f3b1c663fa23..06aece90daff 100644
--- a/app/services/merge_requests/after_create_service.rb
+++ b/app/services/merge_requests/after_create_service.rb
@@ -5,6 +5,7 @@ class AfterCreateService < MergeRequests::BaseService
include Gitlab::Utils::StrongMemoize
def execute(merge_request)
+ sleep 10
merge_request.ensure_merge_request_diff
prepare_for_mergeability(merge_request)
- Create a merge request in the fork.
- Notice that the widget says the merge request must be rebased, when it shouldn't need to be.
- Repeat the same steps with this branch.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Stan Hu