[PUBLIC API] HTTP 5xx errors
irfan-dahir opened this issue · comments
Do your error responses resemble this?
This has become a very reoccurring issue since the past few months so I'll pin it for once and leave an official statement about it here.
The issue
This is an issue caused by a MAL bad response. It's when MAL takes way too long to respond and/or returns a blank response. This could be due to overwhelming traffic by our IP connections.
The Jikan HTTP client thus returns errors like
Status code must be an integer value between 1xx and 5xx.
The HTTP status code "0" is not valid.
This issue is affecting both API versions v3 and v4. However, less on v4 as it's querying most results from a database instead.
What I'm doing to resolve it
- Cache v3 responses for a long period of time
- Discontinuing v3 in favor of v4 - I'll be announcing a timeline in February
- Created v4 which favors a database querying strategy for many API calls unlike v3 which uses an in-memory set/get caching strategy
What you should do to help resolve it
-
If you are on v3, I suggest switching on v4 where these errors are less frequent and will become minimal once v3's discontinued.
-
Cache client-side if you aren't already
-
The success rate of the request is very high if you re-request it right after it fails.
Hope that helps!
In V4 the error will look like this
Message: Undefined array key "url"
Trace: /var/www/jikan-rest/vendor/symfony/http-client/Response/TransportResponseTrait.php on line 129
This is because v4 uses a different HTTP client than v3.
This will now return either
- HTTP 408 Timeout Exception "Request to MyAnimeList.net timed out (10 seconds)"
- HTTP 503
BadResponseException
"Jikan failed to connect to MyAnimeList.net. MyAnimeList.net may be down/unavailable, refuses to connect or took too long to respond. Retry the request!"
These exceptions will no longer generate a GitHub report URL. And it's not advisable to create an issue for it either. For more details on why this happens - read the first pos.
For best practices, I'd still recommend the following:
- If you are on v3, I suggest switching on v4 where these errors are less frequent and will become minimal once v3's discontinued.
- Cache client-side if you aren't already
- The success rate of the request is very high if you re-request it right after it fails.
And to re-iterate on what we'll be doing to improve this:
And what we've done:
- Improved server-side caching strategy
- Discontinued User Lists