Find the answer to your question
Advanced Search
Best Practices for GetSellerList usage when the response is 10007 - "Internal error to the application"
Summary
A problem that can happen at any time is the 10007 error - Internal error to the application.
When this error happens within the context of the GetSellerList call use cases, there is a standard recommendation to work around the problem.
This standard recommendation stems from the fact that when a GetSellerList call returns the 10007 error, the error is due to 1 or more items within the result set triggering the actual error.
There will be a large number of items in the result set that can be returned successfully if we just "remove" the items causing the error from the result set.
The first time this error occurs, the general recommendation is the standard 3 retries for the GetSellerList call.
It is not always necessary to make 3 retries.
If your use case requires a real time response back to an end user waiting in front of a browser, then you may want to go right into the following steps without any retries if the 10007 error happens.
If the call still did not return a successful response, then the following steps should be taken:
1. Break the single GetSellerList call that is failing into 2 GetSellerList calls.
The way to do this is by taking the halfway point between your TimeFrom and TimeTo input time filter values.
Please note that by TimeFrom and TimeTo, we are referring to whatever time filter you are using.
This can of course be EndTimeFrom and EndTimeTo ... or StartTimeFrom and StartTimeTo.
The first GetSellerList call will use your original TimeFrom value, with the TimeTo set to the halfway point.
The second GetSellerList call will set the TimeFrom to the halfway point, and set the TimeTo to your original TimeTo value.
Think of this as using a "binary search" algorithm to get the data that is not causing the error.
2. For the call(s) that still fail with the 10007 error, repeat step 1 above.
Simply break the failed call into 2 calls as described in step 1.
Usually the first time you break your original call into 2 calls, 1 of those calls will return a successful response.
The item(s) causing the error are of course in the result set of the failing call(s).
The number of times you wish to repeat this process will depend on how small of a time range you are willing to skip.
There will be 1 or more time ranges whose result set contains the item(s) that cause the error.
The precision with which you want to narrow the offending time ranges is up to you.
The more precisely you want to capture the data that is not causing the error, the more calls you will make as you narrow down the time ranges.
The precision will depend on your use case in question.
If the use case requires a real time response to a waiting user, then you should move forward with presenting the data after the first split which results in a successful response.
If the use case is in a batch environment, and the gatering of data is the most important thing, then you should iterate through the steps above until the offending time range is very small, on the order of minutes, or until you have found the smallest time range that fails.
The expected volume of the seller can also play a factor in the number of times you repeat the steps above, although it may always not be possible to have an expected volume since your application will likely use standard routines for all users.
Additional Resources
How well did this answer your question?
Answers others found helpful
- Using GetSellerList to retreve a seller's items that were not listed in the certain categories in Java SDK
- How does GetSellerList filter Stores Items when using the End-Time filters?
- Error 36 -An error occurred
- Error 219255 - API call timed out because it has exceeded the predefined SLA for the call
- Error 21359 - Input transfer has been terminated because your request timed out.