Hello, Im having an issue the the search prediction api. The endpoint is only updating once every 15 seconds or so. Here are two example endpoint URLs:
Both URLS are showing the same search predictions if queried close together.
Seems like a caching issue to me but Shopify chat wasn’t able to help me.
Any insight is appreciated. Thanks, Dylan.
@Shopify_77 are you aware of this and on the case?
I sent support another email. I’m seeing this issue on all Shopify sites using the API.
Here is the dawn theme as an example:
I am experiencing the same issue. Their API appears to incorrectly ignore the query ('q’) parameter when determining a server-side cache hit/miss. The other API parameters, such as ‘fields’ or ‘limit’, will correctly influence the cache.
You can verify this theory by viewing https://basicify.myshopify.com/search/suggest?q=red&resources[type]=product&resources[limit]=3§ion_id=site-predictive-search then https://basicify.myshopify.com/search/suggest?q=blue&resources[type]=product&resources[limit]=2§ion_id=site-predictive-search in rapid succession. They show different results because the ‘limit’ parameter is different (thus resulting in a cache miss). However if you view those URLs with the same ‘limit’ parameter (but with different ‘q’ values), they will return identical results (due to a cache hit).
Can the @Shopify_77 dev team please look into this? I believe you need to add the ‘q’ parameter to your caching keys.
I’ve gone through @Shopify_77 support twice now and they said they are looking into it. They seem to think its a developer issue and not an API issue because I’ve been the only one who has reported the issue (despite proving the issue exists on all stores I’ve tested). If anyone opens a ticket, you can reference my tickets: 29022495 and 28997680 (Might save some hassle haha).
I also contacted support. Fingers crossed they fix this issue. 
We are also facing the same issue on our website www.aromatierra.com
Any luck anyone? This is a very critical issue, I hope it gets addressed soon!
I spoke to the support team, and was told they are looking at the issue - my ticket number 29034400.
Is there a way to track these tickets? I was just sent this ticket number on email without any tracking link
Not that Im aware of.
Update from Shopify Support team:
Thank you for your prompt response and for your patience in dealing this with me. I have discussed this further with the Partner specialist and was advised to have this escalated to them so they can investigate into this further. Partner Specialist works through email and once they were able to figure it out, they will be reaching out to you via email.
Lets hope its fixed soon!
Looks like it is fixed – works for me in the limited testing I did.
Can you confirm @ryanwcss , @DylanUurainen , @NZ ?
@para0123 Working for me too! I haven’t heard back from Shopify though.
Caveat for all the below, caches and rate limiting are obnoxious things to work with as a developer and moreso to support as a software provider
So be sure to rule those things out aggressively before counting something as reproducible or supports dismissiveness is 100% valid.
At least they did end up following through and the posts core issues seems to have been resolved , it still raises the meta issue of how they handle bug reports overall:
They seem to think its a developer issue and not an API issue because I’ve been the only one who has reported the issue
@DylanUurainen and other developers.
So we all know that’s not how bug reporting works ,the bug exists and is reproduceable or it doesn’t(as not-reproducible or indeterminate).
Your there helping them fix a bug they have, with your time and experience.
Don’t accept something like that, refute it immediately as the silly behavior it is either from crude-process or rep-inexperience:
*all the exact steps is important I’ve had many issues where they skip important steps and then say it works fine on their end and immediately close the ticket ?.
Dismissiveness is yet another roadblock keeping shopify development from ever being a first class experience.
The roadblock type of that above dismissal from support on any platform|software is 100% bunk parroting process claptrap and should be called out the second a platforms support rep says something so dismissive.
It undermines confidence in a platforms api and development support when process > people being roughshod by that process.
If you have a verifiably reproduceable* bug and a platforms support rep says something so silly consider also just asking for someone else to replace that support rep in the ticket (a supervisor|more-experience-rep ) as they’ve already indicated a sentiment of: #1 not believing you ,#2 a willingness to waste your time , or #3 that you are wasting their time.
For shopify if there is zero-movement on the issue and you feel social consider just tweeting at @shopifydevs along with a video of the issue and it’s steps or utilizing the partner-slack. Unless the bug is security related in which case immediately pass go and head to hackerone for shopify’s whitehat program.
*reproduceable bug = clean environment, no cache issues, defined steps, rigour, etc
Over a decade I’ve had many experiences like DylanUurainen just had on shopify, either directly as partner ,or on behalf of merchants, and it gets so tiresome to have to push through artificial friction so much so that most of the time it can be much more productive to make workarounds than bothering to waste time on support trying to contribute to platform resiliency.
So it’s very nice to hear that this was resolved after an initial dismissal, thanks for the follow-ups DylanUurainen .
Yes t0 support should behave as a firewall for non-bugs that seem like bugs to weed out time wasting user-error(s) crying wolf. However any type of baked-in dismissiveness when provided reproducible steps is just a corrosive support process clogging up the platform. Tough balance to find and no way to fix that?
Which highlights an issue on the developers side of things: how cloud platform developers make sloppy reproduction test-cases. We cannot freeze stores, or cleanly put into a repo a store or parts of it’s api for public examination that will exist past the point of the bug report and any possible fix. We cannot easily verify the version of stores core, the apps installed, it’s themes, it’s apis, if it’s under any ab-testing, etc. Or test against prior versions of most of those systems.
For example this opening post is now invalid when it comes to verifying the bug ever existed and thus having a target to build things like unit-tests against ajax apis.
Alot of bug instructions end up being text of go to this url click here but not here then here; hoping the reproducer has a clean environment or that are environment was not corrupted, or that the reproducer doesn’t skip vital steps or we forgot to include one /ugh.
On the support side a core problem is shopify has cultivated an ecosystem where reporting a bug is a private ongoing marathon of hurdles for most developers. So there will be heavy survivor bias in anecdotes and procedure as most experiences go untold as do the methods used for success or that lead to failure. Compounded by corporate support culture that results in tier 0 support using a sentiment of “only one who has reported the issue” as DylanUurainen experienced.
Then there’s the fact that getting responses on the forums about api|developer issues seems like such a dice roll you’d get better odds in vegas when you hit an edge case.
On the merchant side this does not go over well when going over the risk profile of using or developing on a cloud platform like shopify. Along with an illusory/growing easy to find sentiment that it’s hard to get basic support at all let alone bug tickets. It goes over like a lead balloon if any stakeholder is risk adverse to systems they will not own or have been burned by other platforms with similar support behavior.
It’s can be a hard sale when the point of a SASS is supposed to save on maintenance but bug reports can just get dismissed or vanish into a blackhole; so sure “saving” on maintenance everything but business issues aren’t getting fixed either (excluding feature entitlements).
While yes the reporting process has been getting better with things like the partners bug-reports form, all the tooling in the world doesn’t mean anything if the people involved say iTs YoUr fAuLT from the get go.
Imagine if security treated security reports with dismissive ease on hackerone.
That would be insane or just plain irresponsible, especially for a publicly traded company.
Again thanks for following through on a bug like this.
After waiting for a shopify response whether you get one or not you can mark your own posts as solutions for future searchers in case this reoccurs.
Got a reply and acknowledgement from Shopify regarding the issue:
Hey Dylan,> > Megan from the Shopify Partner Specialist team here, thanks for reaching out! Aiza let me know that you were experiencing some issues with the predictive search function in a number of stores. Thanks for bringing this to our attention.> > I believe this might be related to a Shopify wide incident that occurred, wherein search results on the storefront were not updating and only showing cached results from the initial search. Our developer were made aware of this, and worked quickly on this, and the issue has now been resolved. Can you please Clear Cache and Cookies and try again, and let me know if the issue continues to exist. If so, I’ll be happy to continue working on this for you to figure out what is going on. If that’s the case, could you also send me a screencast showing the issue, so that I can more accurately work to pinpoint the cause.
Thanks for the support and for also opening tickets if you did. I think that accelerated the speed of fixing the issue.