You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In Slack it was reported that a user had somehow ended up with multiple rows in the GlobalSettings table. This Should Never Happen™. As a result of this, when attempting to update global settings, Vendure (postgres) would randomly pick one of the rows and update it, making it look like the changes were not saved.
To Reproduce
No idea how to reproduce creating multiple rows. However, on investigation I found that the use of .findOne() with no argument is incorrect. I had assumed that it would be fine since there should only every be 1 row. Turns out the current behaviour is not to be relied upon and, in the case that somehow multiple rows get created, it leads to the failure described above.
Expected behavior
There should only be 1 global settings row. If somehow more are created, only a single one should ever be selected, in a deterministic way.
2 points to fix:
Include some error-correcting code that will enforce only 1 row existing.
Don't use empty .findOne(). Make it deterministic with some query criteria, eg. get the earliest created.
Environment (please complete the following information):
@vendure/core version: 1.1.0
Nodejs version: any
Database (mysql/postgres etc): postgres
The text was updated successfully, but these errors were encountered:
Describe the bug
In Slack it was reported that a user had somehow ended up with multiple rows in the GlobalSettings table. This Should Never Happen™. As a result of this, when attempting to update global settings, Vendure (postgres) would randomly pick one of the rows and update it, making it look like the changes were not saved.
To Reproduce
No idea how to reproduce creating multiple rows. However, on investigation I found that the use of
.findOne()
with no argument is incorrect. I had assumed that it would be fine since there should only every be 1 row. Turns out the current behaviour is not to be relied upon and, in the case that somehow multiple rows get created, it leads to the failure described above.Expected behavior
There should only be 1 global settings row. If somehow more are created, only a single one should ever be selected, in a deterministic way.
2 points to fix:
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: