Closed dcroote closed 2 years ago
Note that we decided not to relay the API error message back in the day because these sometimes include sensitive information. Relaying the status code is fine though.
Test 1: Check for status code messages Environment: local eth node, local Airnode, beeceptor API response mocking
Steps: Modify the coingecko example to send requests to a mock Beeceptor endpoint, set up the endpoint to return the 404 code for any request; make request with the local Airnode; change to another code and repeat the request
Expected result: Receive more informative error messages for status codes 404, 301, 403 and 409 Actual result: Matches expected results
Test 2: Check for timeout message presence Environment: local eth node, local Airnode, beeceptor API response mocking
Steps: Modify the coingecko example to send requests to a mock Beeceptor endpoint, set up the endpoint to return a 200 code with a 600 second response; make request with the local Airnode; wait if the request times out
Expected result: Receive a timeout message Actual result: Matches expected results
Steps to reproduce
Run the
coingecko
integration inairnode-examples
, but inintegrations/coingecko/request-utils.ts
replaceEthereum
withBthereum
(or any other non-existent coin) as thecoinLabel
.Present Behaviour
I performed the simple "mistake" listed above, which obviously caused the API call to fail. The on-chain fail tx errorMessage was, somewhat unhelpfully:
Desired Behaviour
A user who make an error in the request could be provided with better on-chain error messages and Airnode has the ability to report more detailed errors, for example the below
ERROR AxiosError: Request failed with status code 404
. A404
would be helpful as the user could then ask themselves why might the page not be found and re-check their request. Full log below: