I'm wondering if this is due to the failure to re-load of an individual build history in AbstractLazyLoadRunMap.java.

Specifically the search(int, Direction) method does a binary search looking for a specific build. When it finds a match it may have to load() the build record from disk. If this fails then it "silently" removes the build that it tried to load and carries on.

R r = load(idOnDisk.get(pivot), null);
    if (r==null) {
        // this ID isn't valid. get rid of that and retry pivot
        hi--;
        if (!clonedIdOnDisk) {// if we are making an edit, we need to own a copy
            idOnDisk = new SortedList<String>(idOnDisk);
            clonedIdOnDisk = true;
        }
        idOnDisk.remove(pivot);
        continue;
    }

Assuming that the failure to load is a (unknown) transient error then that would cause the build to disappear but it would be re-loaded when jenkins is restarted and the on-disk records scanned again.

I haven't seen this failure mode so I'm not able to test directly. If someone is able/willing to take a debug build of the latest jenkins I'll try to find time to add some additional debug logging to see if we can prove/disprove this theory.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to