right.. since the result is coming from a module result (not the recorded moduleset result), that's why restart doesn't help.

thx to abayer, I now understand how Hudson is trying to group module builds under the parent build.. so you could build the whole project and get #123 and then run just module A, which makes #124 of module A but it still falls under project build #123.

what happens here is the delete of the project build is only deleting that record and leaving its module builds around.. other code then interprets these as being individual module builds falling under that earlier parent project, and thus that earlier build now shows the failure status, if the orphaned module build was a failure.

so I think if we fix up the deletion code here so delete of the project build also deletes the module builds, then this issue will be resolved. no orphans left to run off and find new parents

That's great, cause it's another bug that gives me trouble!

Code changed in hudson
User: : mindless
Path:
trunk/hudson/main/maven-plugin/src/main/resources/hudson/maven/MavenModuleSetBuild/main.jelly
trunk/hudson/main/maven-plugin/src/main/resources/hudson/maven/MavenModuleSetBuild/main.properties
http://jenkins-ci.org/commit/32410
Log:
An aggregator style build doesn't necessarily have only 1 build per module,
contrary to comment in this jelly.. you can trigger a build of an individual
module from hudson UI. Refactor this jelly to use the current style most
of the time, and the multi-build style whenever needed.
This will help those affected by JENKINS-6779 as the orphaned builds will
now be visible on the build page, so you can click on and then delete them.

Code changed in hudson
User: : mindless
Path:
trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
trunk/hudson/main/test/src/test/java/hudson/maven/MavenProjectTest.java
trunk/www/changelog.html
http://jenkins-ci.org/commit/32411
Log:
[FIXED JENKINS-6779] When a MavenModuleSetBuild is deleted, delete its contained
module builds too.. this avoids orphaned module builds that then get looked at
in determining the overall result for the prior ModuleSetBuild.. possibly
mysteriously changing the displayed result for that prior build, with no visual
indication as to why (this part just fixed in r32410.. build page will now list
all module builds, so you can see/delete the orphaned module build).