In the initial phases of the project, we decided to not pass along all error responses from HoldingsIQ and instead turn them into 500's (Internal Server Errors) with the idea that end-user need not be aware of the exact error message. But with the use-cases outlined below, it seems good to have those messages pass from HoldingsIQ -> MODKBEKBJ -> UIEH.
Background: Chalmers has experienced some performance issues recently. Some of these issues has been a result of exceeding API limit but error messaging does not indicate. Instead the user sees the KB is not setup message. We need to provide better messaging when the issue is not tied to KB configuration issues.
Pass along messages in the scenarios below: Scenario 1: When the error is not due to API credential configuration OR eholdings app not being installed AND it is due to an exceeded API limit [Status code 429] from HoldingsIQ
Scenario 2: When the error response from HoldingsIQ is a 403 Access Forbidden - Recently when we hit the below endpoint for status checks -
we got the below error message:
{ "Message": "User is not authorized to access this resource with an explicit deny" } Forward these messages to UIEH so we can display errors accurately to end-users.
Perfect, thank you for checking. : This can be closed if has no objections.
Denys Bohdan July 1, 2020 at 11:49 AM
Hi , received error messages are shown, just not as toasts, but simple text messages
Denys Bohdan June 30, 2020 at 12:56 PM
sure, I'll check if that's the case
Sobha Duvvuri June 30, 2020 at 3:30 AM
ok good, I do not think this is something we can verify in the backend . - can you please confirm that if MODKBEKBJ returns this response, then the same will appear in toast messages in UI? Not sure how we can simulate the behavior but probably a mock test in UI might be enough to prove this?
In the initial phases of the project, we decided to not pass along all error responses from HoldingsIQ and instead turn them into 500's (Internal Server Errors) with the idea that end-user need not be aware of the exact error message. But with the use-cases outlined below, it seems good to have those messages pass from HoldingsIQ -> MODKBEKBJ -> UIEH.
Background: Chalmers has experienced some performance issues recently. Some of these issues has been a result of exceeding API limit but error messaging does not indicate. Instead the user sees the KB is not setup message. We need to provide better messaging when the issue is not tied to KB configuration issues.
Pass along messages in the scenarios below:
Scenario 1:
When the error is not due to API credential configuration OR eholdings app not being installed
AND it is due to an exceeded API limit [Status code 429] from HoldingsIQ
Scenario 2:
When the error response from HoldingsIQ is a 403 Access Forbidden - Recently when we hit the below endpoint for status checks -
we got the below error message:
{
"Message": "User is not authorized to access this resource with an explicit deny"
}
Forward these messages to UIEH so we can display errors accurately to end-users.
Some documentation on various error responses from HoldingsIQ can be seen here:
https://developer.ebsco.com/errors