Errors sent by the server are suppressed in the API class

https://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

[jfbeats]

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

[rosmcmahon]

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 ?