How can I refresh data for gitlab merge request?

[graywolf]

I am running into issue with stale data in the merge requests on GitLab. I do see all the merge requests, and new ones are added. But base-rev, head-rev slots are not filled. Looking info forge-gitlab.el, I see that .diff_refs.start_sha is used for base-rev.

When I do

(let-alist (forge-rest (forge-topic-at-point) "GET" "/projects/:project/merge_requests/:topic" nil)
  (message "%s" .diff_refs.start_sha)

I do see correct value (commit hash) echoed, so GitLab does send the value. But I cannot figure out how to access it using (oref (forge-topic-at-point) base-rev).

Does anyone has any idea what I need to do to fill the values?

I am using 0.6.7, the last release.

[yhay81]

This looks like a Forge GitLab backend bug rather than stale local data, so there is no refresh command that can fill these slots in 0.6.7.

The reason is the difference between the two GitLab endpoints:

• Forge's forge--fetch-pullreqs calls the collection endpoint, GET /projects/:project/merge_requests.
• GitLab's collection response includes sha, but not diff_refs. The documented list-response fields confirm that.
• diff_refs.start_sha and diff_refs.head_sha are fields of the single-MR response, which is why your direct request to /merge_requests/:topic works.
• Nevertheless, forge--update-pullreq populates base-rev and head-rev from those missing diff_refs fields.

Also, the GitLab implementation of forge--pull-topic currently just calls the full repository pull (there is even a TODO Pull only the one topic), so pulling the topic separately does not work around it.

Relevant code:

• collection fetch in forge--fetch-pullreqs
• the updater reading diff_refs
• GitLab merge-request API documentation

The proper fix is for the GitLab fetch path to hydrate each list item with GET /projects/:id/merge_requests/:iid before calling forge--update-pullreq (ideally only where the required fields are absent). Then the existing updater will store both revisions. Using .sha could fill head-rev, but it cannot supply the correct start_sha/base-rev, so it is only a partial workaround.

Until Forge implements that, your direct forge-rest call is the reliable way to obtain the values; repeatedly running forge-pull will not change the stored slots. I would report this as a GitLab backend bug, including the observation you already made and your GitLab version if self-hosted.