Uploaded image for project: 'Skara'
  1. Skara
  2. SKARA-1048

Missing integration comment causes mlbridge to throw exceptions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 0.9
    • Fix Version/s: 1.0
    • Component/s: bots
    • Labels:
      None

      Description

      This PR in the jdk project is missing the integration comment:

      https://github.com/openjdk/jdk/pull/3214

      It was integrated back in March, so this isn't a big issue as everything else looks correct. The problem is that today, the author removed the source branch of the PR from his personal fork, which counted as touching the PR, which in turn made mlbridge include it in its query for PRs to process. Normally this isn't a problem, but since this PR has a bad state, mlbridge triggers an exception, which will cause an endless rerun and rethrowing of this exception, sounding the alarm to admins.

      This alarm stopped sounding at 13:04 UTC May 20, just a couple of hours later. I'm not yet sure of why, but here is my best guess. Mlbridge has two modes of fetching PRs for processing:

      1. A "full" fetch which gets all currently open PRs. This seems to happen once every 10 minutes.
      2. The rest of the time, it fetches all PRs, both open and closed, that have been touched in the last 14 days, BUT limited to the first "page" of results.

      I'm yet to better understand the page concept here, but I'm guessing that enough other PRs got touched so that jdk#3214 no longer fits in the first page of results.

      The main issue here is that we can sometimes resurrect bad PRs that cause alarms to be triggered. This issue is about putting something in place to either track PRs that just should not be processed further, or to be more lenient against errors like this.

      Another side issue, that should probably be handled separately, is looking into this way of querying for PRs as it seems closed PRs risk getting starved out from further processing arbitrarily.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              erikj Erik Joelsson
              Reporter:
              erikj Erik Joelsson
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: