RFR: 1687: Workaround bug in GitLab where merge request LIST API may serve stale data

[Erik Joelsson]

On Thu, 1 Dec 2022 16:41:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch provides a workaround for a GitLab bug that we are currently encountering. The issue has been fixed upstream, but until we have it deployed in our instance, we need to work around it.
>> 
>> GitLab sometimes serves stale data for merge requests from list queries. For Skara this means that label changes aren't always picked up. I have verified that up-to-date data is always received when fetching single merge requests by ID, so the patch simply re-fetches MRs to make sure the data is always up to date. I'm also adding logging to track when stale data is detected. This will help us verify (at least empirically) when the GitLab issue resolved for us.
>
> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 201:
> 
>> 199:             var newData = request.get("merge_requests/" + id).execute();
>> 200:             // We can't compare the full json object returned from a list query
>> 201:             // and get query call as they will always be different. The part we
> 
> And you are sure the differences don't matter further down the processing chain?

They don't differ in any way that we care about when processing merge requests. We aren't looking at any of those fields. The only thing I can imagine this affecting is the PullRequestPoller, which may, at least in theory, detect some false positives due to this when detecting if a merge request has been updated or not. So that could potentially happen once 3 hours after a merge request has had its updated_at field updated, but only if the query was still including that 3 hour old result, which it normally shouldn't. So maybe possible, but rare enough so that I don't think we need to worry.

-------------

PR: https://git.openjdk.org/skara/pull/1427