/copy from @mikem/

The image task calls getNextRelease at the beginning if no release value is passed in. Once it gets this release value, it uses it in an initImageBuild call. It is only after that init call completes that we have a build entry that would cause getNextRelease to return a higher value. So we have a timeline something like this.

Task A calls getNextRelease, gets 277
Task B calls getNextRelease, also gets 277
Task A calls initImageBuild, call succeeds
Task B calls initImageBuild, call fails

When we added getNextRelease, we weren't anticipating related builds on top of each other like this, so there is no accounting for this race.

Likely what we need to do is move the call to get_next_release into the initImageBuild handler itself, similar to maven builds. However, in this case we'd only trigger that if the given release was None, to avoid changing existing behavior when then release is specified. We'd alter the image build handlers to simply pass the release=None instead of calling getNextRelease themselves.

There would still be a race possibility if two builds made this call at the same time (though the race would be much harder to hit). We'd likely want to address that possibility as well. Likely that would be a try-rollback-retry loop.