change merging is no longer picking the newest change

[dustin]

See attached, where three changes were merged. They are displayed out of order on the page, and in fact the middle one numerically (4012) was the one that supplied the revision.

[dustin]

521.html

[dustin]

I can't reproduce this externally. I'm using a sendchange loop to send changes every 2s for a 5s build, and the changes come out in the right order, and with the right revision.

Here's what I've got so far, from the db:

• Changes 4011 and 4012 were placed in the same sourcestamp (1976) due to a tree stable timer. Change 4013 was in its own sourcestamp (1977).
• Buildset 1980 points to ss 1976, and buildset 1981 points to ss 1977
• os-leopard BuildRequest 42880 points to buildset 1980, and 42922 points to buildset 1981.

The build-starting process looks like this:

• in maybeStartBuild, unclaimed_requests = [ <br 42880>, <br 42922> ] (sorted by the buildsets' submitted_at)
• it calls _chooseBuild, which simply returns the first - <br 42880>
• that gets merged with br 42922
• Build() gets called with [ <br 42880>, <br 42922> ]
• it sets its .source to <br 42880>.mergeWith([<br 42922>])
• ..which calls SourceStamp.mergeWith
• ..which concatenates the changes as <br 42880>.changes + <br 42922>.changes, or [ <ch 4011>, <ch 4012>, <ch 4013> ]
• ..and calls the SourceStamp constructor, which gets the revision from the last change, and thus should get change 4013's revision.

Clearly, something did not happen as expected here: by the time SourceStamp.mergeWith got called, the build requests were in the wrong order. So either unclaimed_requests is not sorted correctly, or _chooseBuild is misbehaving, or the merging is re-ordering things.

All of those seem pretty bulletproof. unclaimed_requests is properly sorted - I tested by shuffling the list before sorting. _chooseBuild just returns [0]. And while _mergeRequests does use gatherResults, it does so in a fashion that correctly maintains order - I tested by adding a random delay to each _brdictToBuildRequest invocation.

So I'm at a loss to figure out what went wrong here. Which means I can't fix it for 0.8.6 without more evidence.

[dustin]

Let's re-open this if we find more data..