Postgres fixes: Concurrency issue, connection leak, and fixes to guard CRUD operations

[AlejandroEsquivel]

Pull Request Type

• Breaking Change
• Feature
• Bug Fix
• Non-bug Patch (dependency update, non-production code, etc.)

Link to Notion Task or Github Issue

Summary of Feature(s)

Summary of Bug Fix(es)

• The docker images using gunicorn need to use uvicorn workers (WSGI / ASGI incompatibility) due to the FastAPI switch
• The containers were crashing upon coming online (workers were dying) due to workers concurrently attempting to execute the sql statements with the audit function, now using advisory lock
• Using db = next(self.get_db()) was essentially causing connections to proliferate due to not being properly closed, so opted for contextmanager approach
• Also db = next(self.get_db()) was causing some changes not to commit properly so deletions / updates weren't working properly due to inconsistent states during db.commits

Previous Behaviour

• Failed to start in Docker due to WSGI / ASGI incompatibility after FastAPI change.
• In POSTGRES mode workers were dying due to attempting to execute audit function creation SQL statements concurrently.
• Connection leak due to sessions not being explicitly closed
• UDATE / DELETE API CRUD operations were not working

New Behaviour

• No connection leaks
• UDATE / DELETE API CRUD operations working
• Multiple workers able to come up reliably while only one worker executes initialization SQL statements with advisory lock

Other details

• PG Client now has util_ methods, these are utility functions which don't create db connections but rather take db sessions as arguments and perform auxiliary actions for the non util functions which are called directly by API controllers and do start db sessions

Dependencies