While the scripts add data from the source to the destination, users seem to be reaching race conditions seemingly caused by PrimaryKey collisions in some database tables. The currently proposed solution from interaction with the user and observation is to add a setTimeout call between SQL create statements to slow down the process allowing the prior process to complete.
Steps to reproduce the behavior
This occurred during a user's routine migration process. To our knowledge, there aren't any steps outside of what we prescribe in our guides that the users followed.
Additional context
If more context is required, @kasonde or @derrickmehaffy would do their best gather the information required. For now, here's an example of the output they got from the scripts:
Anywhere you see <retracted> is information about the user we'd prefer to keep private but has no effect on the process. It is just three letters, i.e strapi_ecomm_abc_v4.
Bug report
Required System information
Describe the bug
While the scripts add data from the source to the destination, users seem to be reaching race conditions seemingly caused by PrimaryKey collisions in some database tables. The currently proposed solution from interaction with the user and observation is to add a setTimeout call between SQL create statements to slow down the process allowing the prior process to complete.
Steps to reproduce the behavior
This occurred during a user's routine migration process. To our knowledge, there aren't any steps outside of what we prescribe in our guides that the users followed.
Additional context
If more context is required, @kasonde or @derrickmehaffy would do their best gather the information required. For now, here's an example of the output they got from the scripts:
Anywhere you see
<retracted>is information about the user we'd prefer to keep private but has no effect on the process. It is just three letters, i.estrapi_ecomm_abc_v4.