What happened:
When a build starts, corresponding steps are created simultaneously.
However, when multiple builds are triggered in parallel, the total number of step creation operations becomes (number of builds) × (number of steps).
This results in a large number of simultaneous insert operations, which can put a heavy load on the database and cause API response degradation.
We considered using Bulk Insert, but the execution order of steps is currently determined by the id order in the steps table.
Therefore, we need to ensure the insertion order even when using Bulk Insert.
However, insertion order depends on the database implementation — while it currently appears to be preserved, it is not guaranteed by specification.
To address this, we may need to introduce a new column in the steps table to explicitly represent the execution order.
What you expected to happen:
How to reproduce it:
What happened:
When a build starts, corresponding steps are created simultaneously.
However, when multiple builds are triggered in parallel, the total number of step creation operations becomes
(number of builds) × (number of steps).This results in a large number of simultaneous insert operations, which can put a heavy load on the database and cause API response degradation.
We considered using Bulk Insert, but the execution order of steps is currently determined by the id order in the steps table.
Therefore, we need to ensure the insertion order even when using Bulk Insert.
However, insertion order depends on the database implementation — while it currently appears to be preserved, it is not guaranteed by specification.
To address this, we may need to introduce a new column in the steps table to explicitly represent the execution order.
What you expected to happen:
How to reproduce it: