Errors sent by the server are suppressed in the API class
See original GitHub issuehttps://github.com/ArweaveTeam/arweave-js/blob/3dcf421bfb7d4b69eb2e7714c33db6c1adcad4f3/src/common/lib/api.ts#L48-L53
for the get and post endpoints. This leads to error messages being used as the return value as if requests were fulfilled correctly instead of interrupting the logic flow. For example, the createTransaction
method can return an object with the string value '{"status":400,"error":"Not Found: HTTPError: Response code 429 (Too Many Requests)"}'
for its reward and last_tx fields
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Handling Exceptions Returned from the Web API
This function displays error information returned from the API in an alert dialog on your page, as shown in Figure 1.
Read more >Errors | Cloud APIs - Google Cloud
Client does not have sufficient permission. This can happen because the OAuth token does not have the right scopes, the client doesn't have...
Read more >HTTP API Errors - commercetools documentation
API -specific errors, such as ExtensionPredicateEvaluationFailed are only returned for a specific set of endpoints and update actions.
Read more >Handle API errors | Google Calendar
The Calendar API returns two levels of error information: HTTP error codes and messages in the header; A JSON object in the response...
Read more >Handling Service Errors and Exceptions - Microsoft Learn
Here are some tips to handle common service errors that you may encounter. For a comprehensive list of Bing Ads API error codes, ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I don’t know how much of the codebase is at risk of letting error message slide as values, but if you say that the behavior was relied upon a lot internally, it would make sense to limit the scope of the fix to only the commonly used methods exposed by the module and their dependencies, and rethrowing new errors when the status code check fails
just reading this again. i think it’s too late to start throwing these errors here at source - too much code to review and change. we should just check the return value in the relevant places where errors should be thrown and act accordingly. what do you think @jfbeats ?