Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promise.all does not roll back transactions completely in case of errors #5529

Closed
khanh-to-niteco opened this issue Nov 2, 2023 · 1 comment

Comments

@khanh-to-niteco
Copy link

Bug report

Describe the bug

In our project, we sometimes encounter a problem that the data is not consistent. Through our investigation, it seems that there is a problem with using Promise.all in many places in Medusajs code base so the transactions do not roll back completely.

typeorm/typeorm#1014 (comment)
odavid/typeorm-transactional-cls-hooked#100
https://stackoverflow.com/questions/67988319/is-there-any-reason-to-use-promise-all-in-a-typeorm-transaction

For example, below is one snippet of code in Medusajs 1.12.0 , the same usage of Promise.all also exists in Medusa latest 1.17.2

image

We have tried setting up a simple test to check if there is actually a problem with Promise.all, it seems that there is a problem

We tried creating a Promise.all for 3 promises:

  • Promise 1: writes a dummy row to tableA
  • Promise 2: throws an error so the promise is rejected.
  • Promise 3: sleeps for 5 seconds then writes a dummy row to tableB

a. Expectation: no record is written to both tableA and tableB
b. Actual result: the dummy row written by promise 1 is still in the database, the dummy row written by Promise 3 is not inserted.

In case Promise 2 does not throw an exception, both records are written to tableA and tableB

Please help to check and advise.

System information

Medusa version (including plugins): 1.12.0
Node.js version: 1.18.0
Database: Postgres
Operating system: Windows

@adrien2p
Copy link
Member

adrien2p commented Nov 8, 2023

Thank you very much for finding this issue. I indeed reproduce that problem and understood why it was happening. I ve opened a pr that we have merged and it should be fixed in the next release.

You can find more here #5543

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants