Yeah, I think it’s the only way for now, but not the best for me. I work with Vite and SCSS/TS. I have to build it almost every time I want to see a preview.
As an update, there is now a new CLI release as of 5 hours ago. I was running 3.94.3 and have now upgraded.
I deleted any cache, node_modules etc. upgraded to the latest version 4.0.0 and have not had any issues as of using it. I will come back here if I do face any further issues but for now upgrading to the latest release has solved any 429 and 403 errors I was previously facing.
Upgrading did not do it for me, still getting hit with 403 for AJAX Cart API consistently and 401 when using Section Rendering API.
App development using the command:
shopify app dev
--theme-app-extension-port=<custom-port>
--tunnel-url=<custom-tunnel>
I’m getting 403’s (using 4.0.0) when hitting any cart endpoints now too - the “–password” workaround that previously worked with the 429s does not do the trick. So this is completely blocking me right now.
Edit: 401 on /cart.js, 403 on /cart/add.js or /cart/change.js
For anyone seeing 403 errors, can you check if those shops are making calls to the cart/clear.js endpoint often?
@Paige-Shopify definitely not the case here. AFAIK not hitting that endpoint at all. Even when not touching the cart endpoints for half a day… the moment I do, I get a 401 or 403. When I tested just now using a standard theme’s remove item from cart… hitting /cart/change.js… I also get for example 401 on /apps/widget/setting and 403 on /shopify_pay/accelerated_checkout showing in the CLI console. Not doing anything exotic or excessive here. Just normal cart actions, not at any high intervals.
Unlike the previous issues, I don’t get completely blocked and unable to access the store. But I effectively cannot work on any cart-related features. Which is a big problem.
If I can be of assistance with e.g. logs… let me know where to send them please.
I was previously getting 429 and 403 errors but now I’m getting 401 errors on customer login and other auth-related routes when running my theme locally (e.g. http://127.0.0.1:9292/account/login). Production works.
-
Shopify CLI version:
4.0.0 -
Network header:
www-authenticate: Bearer realm="…", error="invalid_token", error_description="The access token provided is expired, revoked, malformed, or invalid for other reasons."
This indicates the Shopify CLI dev proxy is forwarding an invalid/expired bearer token to Shopify, and Shopify (served via Cloudflare) is rejecting the request. Cloudflare is the edge that returns the response, but the root cause is the invalid token being sent from the dev proxy/tooling, not Cloudflare itself.
What’s weird is that this only started happening in the last few days, and I’ve changed nothing on my end during that time. so I can only assume some changes have been made elsewhere. I really need someone to investigate this.
Please have some patient and avoid tagging so many Shopify staff members. It hasn’t even been 24 hours since your last post.
401s are unrelated to 403s and 429s. We expect they should be a transient issue which could be fixed by restarting your session. We have an idea to investigate to fix this bug which we need time to prioritize
403s vs 429s
We did ship the fix for 429’s and expected improvement. The 403’s may have started due to an entirely separate incident that happened this week. Good news is - A fix is incoming for 403s.
We have an investigation on going into more long term and resilient improvements. We will have an update next week.
Alright not related to 429’s but after a whole week and a half of running into issues with auth endpoints on 127.0.0.1:9292… I have finally managed to eliminate 401 errors on customer login and other auth-related routes and I can now continue doing my job.
What I’ve found:
Shopify versions 4.0.0+ throw 401 errors on any auth-related action such as login, create account etc.
The error:
www-authenticate: Bearer realm="…", error="invalid_token", error_description="The access token provided is expired, revoked, malformed, or invalid for other reasons."
The fix:
Rollback to version 3.87.4 and it should start working fine again.
See this thread where a similar issue is talked about, this time, regarding cart actions (not resolved yet either since Jan 27th)