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

feat: incorporate api commons exception handlers #175

Merged
merged 5 commits into from Apr 29, 2024

Conversation

lchen-2101
Copy link
Collaborator

closes #162

status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
content=f"The period ({period_code}) does not exist, therefore a Filing can not be created for this period.",
raise RegTechHttpException(
status_code=status.HTTP_404_NOT_FOUND,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@billhimmelsbach @shindigira @meissadia not sure how far along front end is with the status code; is it ok to switch most of the 422s in the filing API which are filing doesn't exist, submission doesn't exist, or filing period doesn't exist to 404s? It makes more sense in my mind; since in this example a filing period doesn't exist, therefore a not found error.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am going to take your updates here and build a wiki page with response codes based on when and we can discuss those during devchat?

return JSONResponse(
status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
content=f"The period ({period_code}) does not exist, therefore a Filing can not be created for this period.",
raise RegTechHttpException(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe more of a stylistic thing, but throwing an exception for non-200 responses, and let exception handlers deal with the rest looks better in my eyes; thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen both ways, and I don't have a preference but sticking with one way is ideal. I know there are a couple of places where we're raising and HttpException but others we're returning JSON responses. Philosophically non-200 responses are errors/exceptions/deviations from happy-path so raising versus returning makes a lot of sense. I say we go with that as a standard approach across the board.

Copy link

github-actions bot commented Apr 24, 2024

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)
Lines missing
  src/sbl_filing_api
  main.py
  src/sbl_filing_api/entities/repos
  submission_repo.py
  src/sbl_filing_api/routers
  dependencies.py
  filing.py
  src/sbl_filing_api/services
  submission_processor.py
Project Total  

This report was generated by python-coverage-comment-action

jcadam14
jcadam14 previously approved these changes Apr 24, 2024
Copy link
Contributor

@jcadam14 jcadam14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I like the use of raise instead of JSONResponse with a status code. Just need to fix the merge again

@jcadam14 jcadam14 dismissed their stale review April 24, 2024 20:58

Merge conflict, fix that and it's good to go.

@jcadam14 jcadam14 merged commit 50bfcad into main Apr 29, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorporate RegTechHttpException from API commons lib
2 participants