🎨 web-server: exception handling framework

[pcrespov]

What do these changes do?

This PR introduces an exception handling framework for the web-server service.

• The interface for this framework is exposed in simcore_service_webserver.exception_handling.
• It follows up with the idea of exception handlers maps _TO_HTTP_ERROR_MAP already used in some plugins of the webserver, e.g. in _folders

These are the highlights:

1. Exception Handling Concept
   Inspired by Starlette's exception handlers, this implementation adapts the concept to aiohttp. Exception handlers are callables that process exceptions and determine the appropriate response to return when errors or handled exceptions occur.

The following demonstrates how exception handlers (exc_handler) integrate into the HTTP request-response lifecycle:

async def middleware_handler(request: Request, handler: Handler):
    try:      
        resp = await handler(request)   

    except exc_type as exc_value:
        resp = await exc_handler(request, exc_value)  

    finally:
        return resp

2. Map Exception-HttpInfo
   The PR includes tools to simplify the creation of exception handlers using mappings from exceptions to HTTP info that include a status code and a message. See simcore_service_webserver.{plugin}._exception_handlers._TO_HTTP_ERROR_MAP for details.

3. Multiple Integration Options
   Provides flexibility by supporting exception handling via:

   • Context Manager: e.g. within the body of the route's handler function
   • Decorator: e.g. a route or a groupe of routes
   • Middleware: e.g. all routes in the app

Related issue/s

• Error handling

How to test

cd services/web/server
make install-dev
pytest -vv tests/unit/isolated/test_exception_handling*.py

Dev-ops

None

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.09%. Comparing base (42476f3) to head (4705c81).
Report is 1 commits behind head on master.

❗ There is a different number of reports uploaded between BASE (42476f3) and HEAD (4705c81). Click for more details.

HEAD has 27 uploads less than BASE

Flag	BASE (42476f3)	HEAD (4705c81)
unittests	31	4

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6655      +/-   ##
==========================================
- Coverage   88.04%   82.09%   -5.95%     
==========================================
  Files        1550      625     -925     
  Lines       61769    31104   -30665     
  Branches     2110      263    -1847     
==========================================
- Hits        54382    25536   -28846     
+ Misses       7056     5508    -1548     
+ Partials      331       60     -271     

Flag	Coverage Δ
integrationtests	64.70% <63.20%> (+11.35%)	⬆️
unittests	83.63% <100.00%> (-2.68%)	⬇️

Components	Coverage Δ
api	∅ <ø> (∅)
pkg_aws_library	∅ <ø> (∅)
pkg_dask_task_models_library	∅ <ø> (∅)
pkg_models_library	∅ <ø> (∅)
pkg_notifications_library	∅ <ø> (∅)
pkg_postgres_database	∅ <ø> (∅)
pkg_service_integration	∅ <ø> (∅)
pkg_service_library	∅ <ø> (∅)
pkg_settings_library	∅ <ø> (∅)
pkg_simcore_sdk	77.36% <ø> (-8.00%)	⬇️
agent	∅ <ø> (∅)
api_server	∅ <ø> (∅)
autoscaling	∅ <ø> (∅)
catalog	∅ <ø> (∅)
clusters_keeper	∅ <ø> (∅)
dask_sidecar	∅ <ø> (∅)
datcore_adapter	∅ <ø> (∅)
director	∅ <ø> (∅)
director_v2	76.53% <ø> (-14.61%)	⬇️
dynamic_scheduler	∅ <ø> (∅)
dynamic_sidecar	59.80% <ø> (-29.95%)	⬇️
efs_guardian	∅ <ø> (∅)
invitations	∅ <ø> (∅)
osparc_gateway_server	79.79% <ø> (-5.70%)	⬇️
payments	∅ <ø> (∅)
resource_usage_tracker	∅ <ø> (∅)
storage	∅ <ø> (∅)
webclient	∅ <ø> (∅)
webserver	88.50% <100.00%> (+0.99%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 42476f3...4705c81. Read the comment docs.

[sanderegg]

very nice. please have a look at my comments. thanks

[GitHK]

Very nice!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bisgaard-itis]

Cool! This is definitely a great improvement and a step in the right direction.

[bisgaard-itis]

I would have named this subclasses_first. It is not obvious to me what concrete_first does

[bisgaard-itis]

I know I am late to the party (sorry). But I am wondering if you profit from the sorting and traversing the exception types 🤔.
Python has a builtin way to resolve inherritance and you could use that to only traverse the super-types of an exception

exc_handler = None
for type_ in exc_type.__mro__:
    if exc_handler := self._exc_handlers_map.get(type_):
        break
return exc_handler

[bisgaard-itis]

The Starlette/FastAPI approach to exception handlers (using this type of middleware) is quite elegant, but what always confuses me is that when I raise somewhere I don't see if and where that exception will be handled. For that I have to manually "follow" the exception up until I see it reaches the middleware. Perhaps it would make sense to have an easy way to test that a handler for a specific exception type is already handled. And maybe even ensure you cannot add two handlers for the same exception type. But I guess this is closely related to the general question of the python exception mechanism: I cannot know what a given function will raise unless I look into the code.