Database duplicate entry for key 'buildresultsummary.brs_key_number_unique'
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Occasionally during an upgrade, some database failures can be seen on Bamboo logs related to duplicate entries for unique keys or Integrity constraints violated, preventing data insertion into the BUILDRESULTSUMMARY table. The following error is reported in the logs:
Caused by: java.sql.BatchUpdateException: Duplicate entry 'TEST-TS-2234' for key 'buildresultsummary.brs_key_number_unique'
at jdk.internal.reflect.GeneratedConstructorAccessor606.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at com.mysql.cj.util.Util.handleNewInstance(Util.java:192)Environment
All supported versions of Bamboo, connected to an external database.
Diagnosis
The following can be found in the <bamboo-home>/logs/atlassian-bamboo.log:
ERROR [10-BAM::PlanExec:pool-16-thread-2] [ChainExecutionManagerImpl] Plan 'TEST-TS' could not be started. could not execute batch; SQL [insert into BUILDRESULTSUMMARY (CREATED_DATE, BUILD_KEY, PLAN_NAME, BUILD_NUMBER, BUILD_STATE, LIFE_CYCLE_STATE, BUILD_DATE, BUILD_CANCELLED_DATE, BUILD_COMPLETED_DATE, DURATION, PROCESSING_DURATION, TIME_TO_FIX, TRIGGER_REASON, DELTA_STATE, BUILD_AGENT_ID, STAGERESULT_ID, RESTART_COUNT, QUEUE_TIME, MARKED_FOR_DELETION, ONCE_OFF, CUSTOM_BUILD, REBUILD, LOG_SIZE, VARIABLE_CONTEXT_BASELINE_ID, FORMAT_VERSION, FAILURE_TEST_COUNT, SUCCESS_TEST_COUNT, TOTAL_TEST_COUNT, BROKEN_TEST_COUNT, EXISTING_TEST_COUNT, FIXED_TEST_COUNT, TOTAL_TEST_DURATION, QUARANTINED_TEST_COUNT, SKIPPED_TEST_COUNT, CONTINUABLE, FIXED_IN_RESULT, SPECS_RESULT, MERGERESULT_ID, BUILD_TYPE, BUILDRESULTSUMMARY_ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 'CHAIN', ?)]; constraint [buildresultsummary.brs_key_number_unique]; nested exception is org.hibernate.exception.ConstraintViolationException: could not execute batch
org.springframework.dao.DataIntegrityViolationException: could not execute batch; SQL [insert into BUILDRESULTSUMMARY (CREATED_DATE, BUILD_KEY, PLAN_NAME, BUILD_NUMBER, BUILD_STATE, LIFE_CYCLE_STATE, BUILD_DATE, BUILD_CANCELLED_DATE, BUILD_COMPLETED_DATE, DURATION, PROCESSING_DURATION, TIME_TO_FIX, TRIGGER_REASON, DELTA_STATE, BUILD_AGENT_ID, STAGERESULT_ID, RESTART_COUNT, QUEUE_TIME, MARKED_FOR_DELETION, ONCE_OFF, CUSTOM_BUILD, REBUILD, LOG_SIZE, VARIABLE_CONTEXT_BASELINE_ID, FORMAT_VERSION, FAILURE_TEST_COUNT, SUCCESS_TEST_COUNT, TOTAL_TEST_COUNT, BROKEN_TEST_COUNT, EXISTING_TEST_COUNT, FIXED_TEST_COUNT, TOTAL_TEST_DURATION, QUARANTINED_TEST_COUNT, SKIPPED_TEST_COUNT, CONTINUABLE, FIXED_IN_RESULT, SPECS_RESULT, MERGERESULT_ID, BUILD_TYPE, BUILDRESULTSUMMARY_ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 'CHAIN', ?)]; constraint [buildresultsummary.brs_key_number_unique]; nested exception is org.hibernate.exception.ConstraintViolationException: could not execute batch
at org.springframework.orm.hibernate5.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:212)
at org.springframework.orm.hibernate5.HibernateTransactionManager.convertHibernateAccessException(HibernateTransactionManager.java:785)
[...]
Caused by: java.sql.BatchUpdateException: Duplicate entry 'TEST-TS-2234' for key 'buildresultsummary.brs_key_number_unique'
at jdk.internal.reflect.GeneratedConstructorAccessor606.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at com.mysql.cj.util.Util.handleNewInstance(Util.java:192)We can check the database for the next build number and the current build number with the SQL query below to identify any builds that have data inconsistency:
select brs.build_key, bn.next_build_number, brs.build_number from build_numbers bn
join build b on bn.build_id = b.build_id
join buildresultsummary brs on brs.build_key = b.full_key
where bn.next_build_number = brs.build_numberThis article can also help identify if any database table has inconsistencies: How to check all the Bamboo database table constraints.
Cause
This happens when Bamboo tries to save the current build number in the database which is the same as the next build number. E.g., when looking at the Bamboo UI, the build number is set to 4 and when running this build, we would expect that the next build number is 5, but when looking into the database the actual build number is already set to 5.
Another possible cause is when there are two separate Bamboo instances connected to the very same database at the same time.
Solution
Usually, Bamboo will fix this itself by running the build plan once again. However, if the issue persists and you find data inconsistencies when performing the steps from the Diagnosis section, please contact Atlassian Support to assist in altering the next build number in the database.
In case the query from Diagnosis returns no results, please make sure that there aren't two separate Bamboo instances connected to the same database at the same time.