Yes, we can check if build_number in plan_vcs_table is not higher than maximum build number of the plan.
If that happens we should just clear such entries.

Is it possible to write some defensive code to handle this situation when it occurs?

@Mark
What I mean it is not a recurring issue. Yep, there might be more Plans borked, but they were all borked sometime in the past. My guess: deleting and then recreating those plans didn't clear plan_vcs_history table. My point is, after clearing the table CBAC will be perfectly fine.

@Przemek
If there entries in plan_vcs_history that have build_number > max build number of plan then Bamboo can't recover from that.

Isn't that something from which Bamboo should recover on its own?

It's not 'second time', this build has this issue from build number 1.

Not sure what you mean here? DO you mean that the specific plan was broken? From the two issues, it seems like they're from different plans?

https://confluence-bamboo.atlassian.com/browse/CONFSTAB-LARGEIMPORTEXPORT-211
https://confluence-bamboo.atlassian.com/browse/CONFSTAB-CWD-119

It's not 'second time', this build has this issue from build number 1.
I think it could have been caused by missing deletes in DeletionService and that has been fixed some time ago.

I raised https://extranet.atlassian.com/jira/browse/BUILDENG-1216 for Adrian to check out the workaround.

Once could be unlucky, but twice is certainly a problem.

ight
We definitely saw it happen more often than that. We did change the plans from svn to git a while ago so there might be some wacky data somewhere.

Marcin posted a workaround @ BAM-10377.

This sounds a like genuine issue though. Once could be unlucky, but twice is certainly a problem.

Can we workback from the logging code and see how it would run into this path? Maybe if a Git repor was created (not made into a default) and then moved into a default build?

Even if it isn't a bug with Bamboo, we need a way to clean up the data on CBAC so it stops happening with new builds.