P2
When the PR bot marks an MR as "rfr", this is sometimes not picked up by the MailingListBridgeBot and NotifyBot. This seems to be a GitLab/OraHub issue, where a certain query, for a certain user, sometimes gets stuck with stale data. Once stuck, it doesn't seem to ever automatically unstuck itself. The only remedy I've seen so far is touching the MR again in some way.
I have also observed that performing the same query as a different user will serve up to date data. Fetching the same MR data using a different API will also serve updated data. The original query with the original user will however keep serving the stale data even after this.
It's possible that the recent improvements to performance and query efficiency in the Skara bots, especially with GitLab, may have caused this issue to arise more often. We are likely reacting faster to new MRs and doing the initial touch ups and label adding quicker than before, possibly within the same minute. Given how GitLab refuses to provide coherent updates within the same minute already, that does seem like it's likely making things worse.
This behavior looks to be caused by https://gitlab.com/gitlab-org/gitlab/-/issues/372595, which has been fixed, but not yet deployed where we are using it. Until it is, we need to employ a workaround. The best I can come up with is to always refetch any MR that we get from the LIST API. I have verified that when getting the MR by ID, the label data is up to date. It does seem like the cache eventually expires (in <3h in my very limited experiment) so we could reasonably limit the refetching to PRs with updated_at within the last few hours.
I have also observed that performing the same query as a different user will serve up to date data. Fetching the same MR data using a different API will also serve updated data. The original query with the original user will however keep serving the stale data even after this.
It's possible that the recent improvements to performance and query efficiency in the Skara bots, especially with GitLab, may have caused this issue to arise more often. We are likely reacting faster to new MRs and doing the initial touch ups and label adding quicker than before, possibly within the same minute. Given how GitLab refuses to provide coherent updates within the same minute already, that does seem like it's likely making things worse.
This behavior looks to be caused by https://gitlab.com/gitlab-org/gitlab/-/issues/372595, which has been fixed, but not yet deployed where we are using it. Until it is, we need to employ a workaround. The best I can come up with is to always refetch any MR that we get from the LIST API. I have verified that when getting the MR by ID, the label data is up to date. It does seem like the cache eventually expires (in <3h in my very limited experiment) so we could reasonably limit the refetching to PRs with updated_at within the last few hours.
