test-infra: tide should not fail to sync subpool with unmergable pr that is already merged

What happened:

jsonPayload: {
  base-sha: "9e853ce03cf83525699f5a623372c6b09694ab9e"   
  branch: "master"   
  component: "tide"   
  controller: "sync"   
  error: "failed merging [16641]: [PR is unmergable. Do the Tide merge requirements match the GitHub settings for the repo? Pull Request is not mergeable]"   
  file: "prow/tide/tide.go:410"   
  func: "k8s.io/test-infra/prow/tide.(*Controller).Sync.func2"   
  level: "error"   
  msg: "Error syncing subpool."   
  org: "kubernetes"   
  repo: "test-infra"   
 }

and yet https://github.com/kubernetes/test-infra/pull/16641#event-3103161369 is already merged ??

What you expected to happen:

tide should continue merging and not fail to sync the subpool

How to reproduce it (as minimally and precisely as possible):

no idea!

Please provide links to example occurrences, if any:

see above link and the log snippet

Anything else we need to know?:

this is bizzare /area prow

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 23 (16 by maintainers)

Most upvoted comments

@pabrahamsson I’d poke the PR with a comment to try to fix the search indexing. It sounds like GH has enough examples for the time being. This was the last response from May 4th:

Thanks for all the details. We investigated and found this to be the result of stale search indices. We therefore started working on a patch which will effectively restart failed indexing jobs.

I don’t have an estimate on when this fix will ship, but we have all the info we need, so you can go ahead and comment on the pull requests in question and unblock your developers.

Thanks for your patience and collaboration in this matter.

cjwagner on May 6, 2020

@DoomGerbil Thanks for sharing here. I’ve included a link to your comment in the email thread with GH support.

cjwagner on Apr 30, 2020

To risk asking a really dumb question: if a PR is unmergeable, why not just move on to the next PR and try merging that? We have seen many times that it is unwise to assume that PRs that we think are mergeable actually always are.

We see lots of single PR failures in interesting ways. It’s not clear to me that this should hold up the rest of the repo.

Katharine on Mar 26, 2020

It was not, which was a little surprising to me.

Katharine on Mar 6, 2020

We have seen this behavior when GitHub’s search index becomes incorrect. If that is the case, commenting on the PR is enough to resolve the problem, but we should still report it to GH support so they can address the bug. Did you by chance see if the PR was showing up in queries for open PRs in the repo (using GH search UI not the API)?

cjwagner on Mar 6, 2020