[Mzsd]

Summary

Fixes a crash when the Postgres connection is dropped or interrupted (e.g. psycopg.errors.AdminShutdown, OperationalError). Previously this reached the generic unhandled exception handler and surfaced as a bare 500 with no indication it was a database issue, reproduced locally by running RYD against a real Postgres container and killing the backend serving its pooled connection mid-session, which crashed the request and produced a "Server Error" page on iati-account-web, matching the traceback in the issue.

Changes

• Enabled pool_pre_ping on the FGA provider's SQLAlchemy engine, so a dead pooled connection is detected and silently replaced before use instead of failing the request that draws it from the pool. Verified this prevents the crash: killing the backend connection and repeating the same request no longer errors.
• Added a dedicated exception handler for sqlalchemy.exc.DBAPIError, so any connection failure that still slips through is logged clearly as a database error and returned as a 503 rather than 500.
• Added unit tests for the new handler.

Files changed

• src/register_your_data_api/auth/fga/fga_provider_db.py
• src/register_your_data_api/exception_handlers.py
• tests/unit/test_exception_handlers.py

Related issues

Closes #69 - Psycopg database connection exceptions are not handled

[simon-20]

This is good @Mzsd. I have just one request:

Returning 503 Service Unavailable implicitly tells the client they should try again later.

But some of the errors that are subclasses of sqlalchemy.exc.DBAPIError (e.g., IntegrityError) are not errors that will be fixed by retrying.

So, I would suggest:

• separate off the handling of OperationError and AdminShutdown (and any other database errors you can find in the docs that are clearly runtime errors) and return 503 for them
• handle DBAPIError after the above and return 500 for it

[Mzsd]

This is good @Mzsd. I have just one request:

Returning 503 Service Unavailable implicitly tells the client they should try again later.

But some of the errors that are subclasses of sqlalchemy.exc.DBAPIError (e.g., IntegrityError) are not errors that will be fixed by retrying.

So, I would suggest:

• separate off the handling of OperationError and AdminShutdown (and any other database errors you can find in the docs that are clearly runtime errors) and return 503 for them
• handle DBAPIError after the above and return 500 for it

Ok I will adjust that bit - thanks

[simon-20]

@Mzsd, this is good to go - can you just add a commit updating the version in pyproject.toml and adding a suitable CHANGELOG entry? We can then deploy it to dev to verify all is good.

[Mzsd]

@Mzsd, this is good to go - can you just add a commit updating the version in pyproject.toml and adding a suitable CHANGELOG entry? We can then deploy it to dev to verify all is good.

@simon-20 Entry added!