[MGNLRESTCL-43] Handle errors in a REST response Created: 14/Feb/19 Updated: 20/Aug/21 Resolved: 18/Nov/19 |
|
| Status: | Closed |
| Project: | REST Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.0 |
| Type: | Story | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Quach Hao Thien |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0.25d | ||
| Time Spent: | 13d 0.5h | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||
| Epic Link: | Declarative REST clients | ||||||||||||||||||||||||||||||||||||
| Sprint: | Declarative REST 9, Declarative REST 10 | ||||||||||||||||||||||||||||||||||||
| Story Points: | 13 | ||||||||||||||||||||||||||||||||||||
| Description |
Acceptance Criteria:
To be decided: What is the behaviour by default? How exactly can the things be configured? |
| Comments |
| Comment by Christopher Zimmermann [ 06/May/19 ] |
|
The REST client can handle standard error conditions, and return a standard code to a response:
The consumer of the client can handle it how it wants. Probably the REST client system would also provide translatable message strings for those conditions which can be used as error messages in the UI. |
| Comment by Christopher Zimmermann [ 02/Oct/19 ] |
|
Better error messages in restfn. Currently if there is any problem with the RestClient configuration or with the call, you get no useful information in the FTL error message or in the Magnoila Logs. Very hard to debug any issues. |
| Comment by Jorge Franco [ 04/Nov/19 ] |
|
So, the common behavior is add as many information in the log about the problem with rest call, giving details about url, error and response. Using restfn functions: in public instances will return an empty map, in author instances will show yellow error screen with information. The invocation of rest calls using java will return the error in some way (actually working on that). Information in the log will happen always, even in exceptionHandler or timeoutHandler are defined. |
| Comment by Quach Hao Thien [ 18/Nov/19 ] |
|
for QA: |
| Comment by Dai Ha [ 19/Nov/19 ] |
|
Verified with ce, rest-client, cache at master. |