You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Above the statement concerning the output, is typically a table of different response codes, example -
`HTTP Code
Description
Schema
200
TransactionIDResponse contains a transaction information
transactionID
400
Bad Request
string
401
Invalid API Token
No Content
500
Internal Error
string
default
Unknown Error
No Content`
Confusion arises between the schema defined in the table, particularly for an error, and the expected Content-Type of the message and the different SDK's error handling.
For example, the PureStake API had the result of a 400 bad transaction returned as application/json content type although the actual output is not JSON but a string TransactionPool.Remember: txn dead: round 5395354 outside of 5153790--5154790.
This can cause parsing errors in the JS SDK library when it expects a JSON object. We switched it to produce 'text/plain' but are not certain if that was correct.
Ideally everything would return as JSON and the SDKs could properly parse out errors like the above. If not feasible, some clarification in the documentation about the expected Content-Type for the different response codes.
The text was updated successfully, but these errors were encountered:
Following up on this, using the sandbox I constructed a local curl command with a bad transactions and did get a 'text/plain' response. Moving forward with the assumption then that all errors specified as 'string' return as 'text/plain'.
`root@7ff87f1bb76a:/opt/algorand/node# curl -v -X POST --data-binary @./400_test_2.tx -H "X-Algo-API-Token: $(cat ./data/algod.token)" -H "Content-Type: application/x-binary" http://127.0.0.1:4001/v1/transactions
Note: Unnecessary use of -X or --request, POST is already inferred.
In the documents here - https://developer.algorand.org/docs/reference/rest-apis/algod/ - all endpoints state that they have an output
Content-Type
in the formatapplication/json
.Above the statement concerning the output, is typically a table of different response codes, example -
Confusion arises between the schema defined in the table, particularly for an error, and the expected
Content-Type
of the message and the different SDK's error handling.For example, the PureStake API had the result of a
400
bad transaction returned asapplication/json
content type although the actual output is not JSON but a stringTransactionPool.Remember: txn dead: round 5395354 outside of 5153790--5154790
.This can cause parsing errors in the JS SDK library when it expects a JSON object. We switched it to produce 'text/plain' but are not certain if that was correct.
Ideally everything would return as JSON and the SDKs could properly parse out errors like the above. If not feasible, some clarification in the documentation about the expected
Content-Type
for the different response codes.The text was updated successfully, but these errors were encountered: