Is anyone aware of a results limitation for the it...
# suitecommerce
c
Is anyone aware of a results limitation for the item search API when working with 5,000+ items? We receive a search failed error from the item search API when attempting to query with an offset of 5,000 or more. We discovered this from an error on the SuiteCommerce results page when attempting to view page 209 of the search results. I then attempted to hit the item search API directly to determine which result was causing the issue. I was successful with an offset up to 4,999 and a limit of 1, but I started to receive the error from anything over 5,000.
s
It is my understanding that there is no limit on the returned number of items, so I am surprised it fails at 5000.
I think you should raise a case.
c
Thank you, Steve. I will open a support case for this.
k
@Cory did you get anywhere with this support case? I think we ran in to this same thing....we were checking images that weren't displaying and paged through the search at 72/page, then errored at about 4968....
c
@kkennedydesign I have not heard anything back as of yet, but I can let you know when we do. I actually first came across this error when checking for missing images as well. Have you tried calling the item search API with the query string parameters "&offset=4999&limit=1" ? This successfully returns results for me, but when I change the offset to 5000, that's when I first see the error, and it continues past 5000.
s
Cory, what's the case number please?
k
We had intermittent thumbnail images dissappearing in search that were not missing on the pdp so we were paging through...died at about 5000 with an internal error. I tried your test above and it also failed.
s
@Cory @kkennedydesign I am talking to the PM about this issue and it seems to be that there has been some miscommunication. It appears that there is no limit to the number of items you can have in the index but there might be a limit on the number of items returned. That limit doesn't seem to be hard limited to 5,000 but rather a system resources limitation.
Can I ask what your use cases are for this?
(The API is designed for use within the web store context, so if your shoppers have reached the 5,000th item in a product list and still can't find what they're looking for, this is a sign of a different problem 😉 )
k
in our case we were using it qa the images....in sites we have worked on, they normally wouldn't have 5000 items. It seems like it could be more elegantly handled though, rather than "internal error".
s
I agree. I can't find Cory's case, but I have found a recently created issue to improve the error reporting on this, as well as getting it docced
c
@Steve Goldberg Unfortunately, I just found out that the case has not been submitted yet, so I do not have a case number. Would you suggest that I still submit the case? Also, I came across this the same way as @kkennedydesign, when running the script to determine which items were missing images. I then went to test it out using the search with SuiteCommerce, and discovered the error again.
s
You'll probably get the same response that I just gave you but you can. (I don't know what it's like for partners when they raise cases – do you guys only get a set amount of support time? In which case, it's probably not worth it.)
c
I'm not aware of a limit on our use of support time, but you're probably correct that it's not worth it at this point. Do you have a suggestion for how we could determine missing items when the item count is over 5,000? We're looking at roughly 40,000 at the moment, but it will be up to 100,000.
s
I honestly don't know. I will poke around and see if I can find some additional information
c
Thanks, Steve. I appreciate that.
s
So the limitation is an enforced one by the Elastic search service and one we cannot control. For your use cases, we recommend using bulk tools / API built into NetSuite (however, I can't tell you how to use them for checking for missing images, sorry).
c
Not a problem. This gives me a good place to start. Thanks again for all your help.