[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:
Cloners
is cloned by MGNLRESTCL-50 Automatically retry a REST response Accepted
Relates
relates to MGNLRESTCL-100 Cannot render some HTTP response codes Closed
causality
is causing MGNLRESTCL-98 DOC: Example of handling errors Closed
dependency
is depended upon by MGNLRESTUI-5 UI should fail gracefully when Rest D... Closed
is depended upon by MGNLRESTCL-87 Developers can view full REST calls a... Closed
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   

As a developer, I want to handle errors in the response explicitly, and I can trust the connection to provide a good default behaviour, so I can handle errors gracefully.

Acceptance Criteria:

  • I can write to the log on error.
  • I can provide a message to the UI on error.
  • Error handling concept should be applicable to both UI & code, e.g. MAGNOLIA-7465

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:

  • service not availablie.
  • not authorized.
  • Error code in the response
  • Response format is invalid.
  • etc.

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: 
demo could be found in https://git.magnolia-cms.com/projects/MODULES/repos/rest-client/browse/declarative-rest-demo/templates/components/errors-handler

Comment by Dai Ha [ 19/Nov/19 ]

Verified with ce, rest-client, cache at master.

Generated at Mon Feb 12 10:42:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.