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:
"Quantity of reports is not a metric of existence , please have your developers verify they can reproduce this bug as reported using ALL the exact steps* I provided "
*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 🤷.
Bigger Picture - tl;dr I don't keep a blog
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.
