fixed race conditions in the signup page

[epicadk]

Description

Fixes #1019

Type of Change:

• Code

Code/Quality Assurance Only

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Used to same program that caught this bug to verify if it has been solved or not.

Checklist:

• My PR follows the style guidelines of this project
• I have performed a self-review of my own code or materials
• I have commented my code or provided relevant documentation, particularly in hard-to-understand areas

Code/Quality Assurance Only

• My changes generate no new warnings
• My PR currently breaks something (fix or feature that would cause existing functionality to not work as expected)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been published in downstream modules

[codecov]

Codecov Report

Merging #1023 (3a29025) into develop (ca4728a) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #1023      +/-   ##
===========================================
+ Coverage    92.90%   92.92%   +0.02%     
===========================================
  Files           38       38              
  Lines         2073     2079       +6     
===========================================
+ Hits          1926     1932       +6     
  Misses         147      147              

Impacted Files	Coverage Δ
app/api/dao/user.py	85.88% <100.00%> (+0.05%)	⬆️
app/database/models/user.py	98.66% <100.00%> (+0.09%)	⬆️

[NenadPantelic]

Hey @epicadk Have you tested what happens if you insert some record that will not cause integrity error, but some other form of error, e.g. DataError if the data is too long? You're catching just integrity error and rollback only in that case, we need a more general approach. DBAPIError or even Exception may help there.

[epicadk]

Hey @epicadk Have you tested what happens if you insert some record that will not cause integrity error, but some other form of error, e.g. DataError if the data is too long? You're catching just integrity error and rollback only in that case, we need a more general approach. DBAPIError or even Exception may help there.

@NenadPantelic If the data is too long then I think we validation will not pass and it will return 400. I am not sure what other types or errors we'd want to handle. 😕 could you provide an example other than the data not matching the database constraints?

[NenadPantelic]

Yes, in this case validators will solve the potential issue. I'm saying that we should protect the DAO layer, cause some DAO objects can be used in multiple controllers and also, we can get some unpredicted errors (transactional, persistence, etc.). In this case, I suppose it's fine on this occasion, cause validations are exhaustive and pretty much detailed and we work with the User model just from that controller, but this was more like a general comment, every layer that provides some service should be protected with its own mechanisms (like we have validations on the frontend, but we do them on the backend too and on the database).

[epicadk]

Yes, in this case validators will solve the potential issue. I'm saying that we should protect the DAO layer, cause some DAO objects can be used in multiple controllers and also, we can get some unpredicted errors (transactional, persistence, etc.). In this case, I suppose it's fine on this occasion, cause validations are exhaustive and pretty much detailed and we work with the User model just from that controller, but this was more like a general comment, every layer that provides some service should be protected with its own mechanisms (like we have validations on the frontend, but we do them on the backend too and on the database).

I suppose we could do that. However I don't know if that would be in the scope of this pr. Feel free to open another issue. 😃

[devkapilbansal]

@epicadk can you please include some test cases to check if this works?

[epicadk]

@epicadk can you please include some test cases to check if this works?

Done 😅 .

[epicadk]

Seems like github actions won't allow more than a single thread for execution. The test can't be added. Reverting the change.

[devkapilbansal]

Seems like github actions won't allow more than a single thread for execution. The test can't be added. Reverting the change.

@epicadk I see the Github Workflow. There you mentioned asyncio.run(make2requests()) which is introduced in Python 3.7 but workflow uses Python 3.6 for testing. Please look into that once.

Also, resolve the conflicts

[epicadk]

@epicadk I see the Github Workflow. There you mentioned asyncio.run(make2requests()) which is introduced in Python 3.7 but workflow uses Python 3.6 for testing. Please look into that once.

Doesn't matter I don't think github actions allows parallel execution of code of the tests also even if there are more than one threads it doesn't mean the code will run in parallel so it doesn't make sense to have tests for this.

[devkapilbansal]

LGTM 👍