Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 [REST API] Respond with 403 when max allowed limit for entities is exceeded #4154

Merged
merged 1 commit into from
Dec 17, 2024

Conversation

MDeLuise
Copy link
Contributor

Overview

This pull request fixes an issue where exceeding the maximum allowed limit for entities resulted in the server returning an incorrect HTTP 500 (Internal Server Error) response. The behavior is now updated to return the correct HTTP 403 (Forbidden) status code when such limits are exceeded, as per service expectations.

Changes

  • Updated the handling of KapuaMaxNumberOfItemsReachedException to ensure it maps to a 403 status code instead of 500.
  • Ensured consistent behavior when the maximum allowed limit is exceeded for all entity types.
  • Enhanced error information to include entity-specific details (entityType) for better traceability and debugging.

Why this is important

The previous 500 response indicated a server-side error, which led to confusion and misalignment with the intended service behavior. These changes ensure that exceeding service-defined limits is appropriately flagged as a client-side issue (403 Forbidden), improving correctness and reliability of APIs.

How to reproduce the original issue

  1. Attempt to create entities (e.g., users) until the service-defined maximum limit is reached.
  2. Observe the server responding with HTTP 500 instead of 403.

Expected Behavior After Fix

  • When the limit is exceeded, the response is now HTTP 403 (Forbidden) with clear error details that include relevant entity information.

Ensure the backend returns HTTP 403 (Forbidden) instead of HTTP 500 (Internal Server Error) when any entity exceeds the maximum allowed limit as defined by service settings.
Copy link

codecov bot commented Dec 12, 2024

Codecov Report

Attention: Patch coverage is 0% with 15 lines in your changes missing coverage. Please review.

Project coverage is 16.76%. Comparing base (38c4367) to head (ea95f48).
Report is 16 commits behind head on develop.

Files with missing lines Patch % Lines
...s/KapuaMaxNumberOfItemsReachedExceptionMapper.java 0.00% 9 Missing ⚠️
...l/errors/MaxNumberOfItemsReachedExceptionInfo.java 0.00% 6 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@              Coverage Diff              @@
##             develop    #4154      +/-   ##
=============================================
- Coverage      16.79%   16.76%   -0.04%     
  Complexity        22       22              
=============================================
  Files           2037     2039       +2     
  Lines          52835    52850      +15     
  Branches        4441     4441              
=============================================
- Hits            8874     8860      -14     
- Misses         43560    43587      +27     
- Partials         401      403       +2     
Files with missing lines Coverage Δ
...l/errors/MaxNumberOfItemsReachedExceptionInfo.java 0.00% <0.00%> (ø)
...s/KapuaMaxNumberOfItemsReachedExceptionMapper.java 0.00% <0.00%> (ø)

... and 3 files with indirect coverage changes

@Coduz Coduz added Bug This is a bug or an unexpected behaviour. Fix it! REST API We hope to REST everyday labels Dec 17, 2024
@Coduz Coduz merged commit 747af8a into eclipse-kapua:develop Dec 17, 2024
34 of 36 checks passed
@MDeLuise MDeLuise deleted the fix-statusCodeMaxNumOfItem branch December 17, 2024 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This is a bug or an unexpected behaviour. Fix it! REST API We hope to REST everyday
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants