I'm using Strapi and trying to check if a category exists before creating it. However, my database actions are not committed properly, and duplicate records are being generated. Here’s my code:

await Promise.all(
    manipulatedData.map(async (strain) => {
        const existsCategory = await strapi.service('api::category.category').find({
            filters: { name: strain.Category },
        });

        if (existsCategory.results.length === 0) {
            await strapi.service('api::category.category').create({
                data: { name: strain.Category },
            });
        }
    })
);

Issues I'm Facing: The code doesn’t execute step by step, and multiple records are created. It seems like Promise.all runs all async operations in parallel, causing race conditions. The category creation should only happen if it doesn’t already exist, but it still creates duplicates.

Questions: How can I ensure that the check and insert operations execute sequentially to avoid duplicates? Is there a built-in Strapi method to handle this scenario more efficiently? Should I use transactions or locks to prevent race conditions? Any guidance would be greatly appreciated!

I'm using Strapi and trying to check if a category exists before creating it. However, my database actions are not committed properly, and duplicate records are being generated. Here’s my code:

await Promise.all(
    manipulatedData.map(async (strain) => {
        const existsCategory = await strapi.service('api::category.category').find({
            filters: { name: strain.Category },
        });

        if (existsCategory.results.length === 0) {
            await strapi.service('api::category.category').create({
                data: { name: strain.Category },
            });
        }
    })
);

Issues I'm Facing: The code doesn’t execute step by step, and multiple records are created. It seems like Promise.all runs all async operations in parallel, causing race conditions. The category creation should only happen if it doesn’t already exist, but it still creates duplicates.

Questions: How can I ensure that the check and insert operations execute sequentially to avoid duplicates? Is there a built-in Strapi method to handle this scenario more efficiently? Should I use transactions or locks to prevent race conditions? Any guidance would be greatly appreciated!

• strapi

Share Improve this question Follow edited Mar 12 at 10:25 DarkBee 15.5k88 gold badges7272 silver badges118118 bronze badges asked Mar 12 at 10:07 DanialDPDanialDP 3511 silver badge1111 bronze badges 4

• fixed this by replacing Promise.all with a for...of loop to ensure sequential execution! – DanialDP Commented Mar 12 at 10:12
• Promise.all does not "execute" anything, it's only waiting for results. It's your map callback that makes the calls. And why did you expect those to happen sequentially? – Bergi Commented Mar 12 at 10:43
• Why do you have duplicate data in your manipulatedData in the first place? It's probably the easiest way to filter those out before even making the first calls – Bergi Commented Mar 12 at 10:48
• I don't know Strapi specifically, but it should offer some find-or-create method that does this in a single step that is transactionally safe – Bergi Commented Mar 12 at 10:49

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

I solved this issue by replacing Promise.all with a for...of loop to ensure that the database operations execute sequentially.

Instead of running all operations in parallel (which caused duplicates), I changed my code to this:

for (const strain of manipulatedData) {
    const existsCategory = await strapi.service('api::category.category').find({
        filters: { name: strain.Category },
    });

    if (existsCategory.results.length === 0) {
        await strapi.service('api::category.category').create({
            data: { name: strain.Category },
        });
    }
}

Why This Works:

• for...of ensures that each database check completes before moving to the next iteration.

• This prevents multiple parallel checks from inserting duplicate records.

• The operations now execute sequentially instead of in parallel.

After making this change, the duplicate records issue was resolved. I hope this helps anyone facing a similar problem!