♻️ Uniform naming of http status codes

[pcrespov]

What do these changes do?

I would like to propose some basic conventions and techniques to increase robustness of error handling as well as consistency across service interfaces (regardless whether they are aiohttp or fastapi-based).

Those will be a set of simple concepts but very "noisy" changes. Therefore, I will do it in three different PRs for clarity and to encourage critics/discussion:

1. Uniform naming of status codes (this PR)
2. Using a base exception class per service. This base class will use pydantic's mixin extended with an automatic code hierarchical error code name.
3. Introducing registration of exception handling for aiohttp. This approach is based on fastapi/starlette exception handling concept extended to automatically document additional responses for each entrypoint.

This first PR focuses on using a consistent naming of status codes throughout the entire codebase. Out of the many the many possible variants available:

• 404 as a raw integer
• aiohttp.web.HTTPNotFound.status_code
• http.HTTPNotFound as http.HttpStatus which is an IntEnum
• httpx.codes.NOT_FOUND as httpx.codes which is an IntEnum
• fastapi.status.HTTP_404_NOT_FOUND as int
  I find the latter the most readable since I can easily match both number and name (not sure about you, but I always mix up codes). Moreover conversion to any of the IntEnum's above is straighforward if needed. The only inconvenient is that it requires installation of starlette. But fear no more 🦸, this PR introduces the same constants in servicelib.aiohttp.status module analogous to fastapi.status but for aiohttp-based services

Related issue/s

• Maintenance

How to test

• all tests in place

Dev Checklist

• No ENV changes or I properly updated ENV (read the instruction)

DevOps Checklist

None

[codecov]

Codecov Report

Attention: 14 lines in your changes are missing coverage. Please review.

Comparison is base (f834b74) 87.3% compared to head (1de6564) 87.1%.

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #5323     +/-   ##
========================================
- Coverage    87.3%   87.1%   -0.2%     
========================================
  Files        1320    1321      +1     
  Lines       54063   54152     +89     
  Branches     1172    1172             
========================================
+ Hits        47201   47219     +18     
- Misses       6612    6683     +71     
  Partials      250     250             

Flag	Coverage Δ
integrationtests	63.7% <58.0%> (-1.3%)	⬇️
unittests	85.2% <88.4%> (+<0.1%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...e-library/src/servicelib/aiohttp/client_session.py	100.0% <ø> (ø)
...c/servicelib/aiohttp/long_running_tasks/_server.py	90.1% <100.0%> (+0.1%)	⬆️
...rary/src/servicelib/aiohttp/requests_validation.py	86.5% <100.0%> (+0.2%)	⬆️
...e-library/src/servicelib/aiohttp/rest_responses.py	91.3% <100.0%> (+0.1%)	⬆️
...s/service-library/src/servicelib/aiohttp/status.py	100.0% <100.0%> (ø)
.../service-library/src/servicelib/archiving_utils.py	82.0% <100.0%> (ø)
.../service-library/src/servicelib/background_task.py	97.9% <100.0%> (ø)
...es/service-library/src/servicelib/logging_utils.py	72.7% <ø> (ø)
...ges/service-library/src/servicelib/progress_bar.py	97.8% <100.0%> (ø)
packages/service-library/src/servicelib/redis.py	94.1% <100.0%> (ø)
... and 27 more

... and 9 files with indirect coverage changes

[bisgaard-itis]

Very cool. Thanks a lot!

[GitHK]

🎉 very nice!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud