Improve error handling in TransmodelGraph - #5192
Conversation
|
Remove Error codes from Legacy Schema |
…o "system-level"
so we can return 500, and not 200 OK.
This removes OtpExecutionResult as an intermediate step
db07f74 to
dfb5388
Compare
|
The node download is timing out again. I'm hopefully fixing it with this commit: 465aca1 |
| case WALKING_BETTER_THAN_TRANSIT: | ||
| api = new PlannerError(Message.TOO_CLOSE); | ||
| break; | ||
| case SYSTEM_ERROR: |
There was a problem hiding this comment.
What happens instead?
There was a problem hiding this comment.
The SYSTEM_ERROR is not returned, it is handled by the GraphQL framework and reported in the errors section of the root response - if we does not know what happen, then we should not return a partial result either - it might be corrupt.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #5192 +/- ##
=============================================
+ Coverage 65.69% 65.80% +0.11%
- Complexity 14723 14741 +18
=============================================
Files 1770 1767 -3
Lines 68556 68525 -31
Branches 7288 7282 -6
=============================================
+ Hits 45037 45094 +57
+ Misses 21025 20942 -83
+ Partials 2494 2489 -5
☔ View full report in Codecov by Sentry. |
leonardehrenfried
left a comment
There was a problem hiding this comment.
The non-Transmodel part is fine.
Summary
This PR cleanup the error handling in TransmodelGraph. Uncaught exceptions, witch before propagated to the Jersey Exception filter are now caught in the
TransmodelGraph#executeGraphQLmethod. I also removed one "layer" in the result chain. TheTransmodelGraphnow return a jakarta Response, not anOtpExecutionResult. This is not 100% pure, but we are not likely to support another protocol than HTTP in the near future, it is also easy to revert.This is based on #5189
Issue
No issue.
Unit tests
New test on result mapper added.
Documentation
JavaDoc only
Changelog
No
Bumping the serialization version id
No