http://validation.linaro.org/lava-server/scheduler/job/2267 is a good example of this.
I found this very confusing at first, but then realized what must be happening. In this case, we have a deploy that failed because it had an error while running LMC. But if you link to the results, it looks like it ran tests, though the serial log says otherwise. I believe what's happening here is that it is failing to deploy, then skipping ahead to the step where it submits results, and pulling results from the previous job off the system.
This could also explain why we sometimes see results that fail to deserialize because they have a duplicate uuid - it's because it's the same result! However, in this case, I'm not sure why that didn't happen. There's definitely a problem with the ordering of things here though, and the old results need to be cleaned up *before* starting a new job. Easiest and safest way would probably be to just make sure we format that partition at the beginning of the job, before we try to create the image.
Another way is to delete the result bundle on both master and test image after downloaded the result.