ZCLI and ZAT not workingAnswered
How to determine if Zendesk is in development mode when adding zcli_apps=true in the URL?
Suddenly ZCLI not working in my computer. I run the command zcli apps:server ./dist and the output is `Apps server is running on http://localhost:4567`. But when I check in netstat there is no application using port 4567. Unlike using ZAT, it is visible in netstat.
Using either ZCLI or ZAT it seems Zendesk doesn't load into development mode.
- OS: Windows 11
- ZCLI(Windows) and ZAT(Ubuntu Subsystem)
- Browser: Chrome and Firefox
I found this issue also. Today I can't test custom app with ZCLI and ZAT.
Support told please go to the community(https://support.zendesk.com/hc/en-us/community/topics) and include as much relevant information in your post as you feel comfortable sharing.
Same here (and the same outcome from Support as well).
The browser gives cross-origin errors in the console that weren't appearing just yesterday.
My team have the same issues. Multiple people can't use local development for different Zendesk instances.
Same problem here. I tried a new API token and it seems zcli apps:validate and zcli apps:package works and uses the new token but apps:server won't show the app in Zendesk. Yesterday everything worked well in another subdomain environment. I'm using Windows 10 + WSL2 Ubuntu + environment variables for authentication.
All of a sudden, `?zat=true` stopped working. Something is broken on the Zendesk side.
Quoting developer experience team, Zendesk is working on a fix at the moment to an issue with local app testing affecting zcli and zat. However, as this fix involves multiple internal teams, it may take some time to roll out. They understand it may not be ideal, but as an interim workaround you can test your apps under development by installing them in your account.
Same issue, is there a timeline here Ahmed?
Hi all! As Ahmed mentioned, this is a known issue and our teams are working on a solution. At the moment, I don't have any timeline, but I'm following this closely and will let you know as soon as I have more information. If it makes anyone feel better (or worse), it's directly affecting work that I was doing today, so I'm very much in the same boat looking for a quick resolution!
Same for us, just coding custom App and stopped working, hope it will be fixed soon, long night shift on-going! :)
Having a similar issue w/ zat. Seeing this error when using the zat command.
Top level ::CompositeIO is deprecated, require 'multipart/post' and use `Multipart::Post::CompositeReadIO` instead!
Top level ::Parts is deprecated, require 'multipart/post' and use `Multipart::Post::Parts` instead!
/home/####/.rbenv/versions/2.6.9/lib/ruby/gems/2.6.0/gems/faraday-0.17.5/lib/faraday/upload_io.rb:65: warning: constant ::UploadIO is deprecated
/home/####/.rbenv/versions/2.6.9/lib/ruby/gems/2.6.0/gems/faraday-0.17.5/lib/faraday/upload_io.rb:66: warning: constant ::Parts is deprecated
Same issue here: locally hosted app for development no longer appearing in apps sidebar panel. No errors command line side loading localhost zcli app server.
In the future, would it be possible to communicate to your customers before rolling out potentially breaking changes like this?
Maybe send an email giving us some heads up like, "Hey, on jan 25. we are rolling out a bunch of potentially breaking changes, we understand that this has the potential to disrupt your development cycle so here is our release schedule."
When I have worked on software of this scale in the past, we always had to have disaster plan in the case of a bad deployment so that we could immediately mitigate any problems we caused. This seems to happen routinely, and it would be really helpful if we had more transparency.
Hi all! I wanted to drop a line in here to let everyone know that this issue has now been resolved. Please let me know if you're still seeing any issues though!
Joseph (and probably everyone else also), I totally understand where you're coming from. When things stop working out of the blue, it's incredibly frustrating for everyone involved. While I don't know the full details of this situation, I can say that this was not a planned change so this was not something that could be communicated ahead of time. On that note, we do post maintenance notifications to admins in Zendesk, as well as in our Service Notification section.
Last but definitely not least, we have a global, 24/7 incident management team at Zendesk that you can read more about here. As a result of the work from that team, we are able to take care of situations like this much faster, with better communications than would be otherwise possible. It doesn't always feel that way when we're in the middle of it, but I can assure you that any time there is an incident at Zendesk, there are a lot of people working hard to get you back up as soon as possible!
Very many thanks for the notification, Greg! Yes, I can confirm that it's up and running again now. Praise Jah! 🙏
Hi Greg Katechis - I've noticed today that testing apps locally using `?zat=3000` is failing - it seems like this feature may still be broken - appending this to a URL in Zendesk usually disables all apps and enables an app from details in http://localhost:3000/app.js
However, currently, appending this does not disable all apps (or attempt to load this app.js file).
Using ?zat=true does correctly do the expected behaviour (but specifically from port 4567).
Hi Cheryl, thanks so much for pointing this out! Just looking into this now, it appears to be an intentional change, but I honestly do not have any insight as to why it was made. I've reached out to the team that is responsible for this and as soon as I hear back, I'll drop a line here. For transparency, they're based in Melbourne, so it's possible that I won't see their response until tomorrow. Apologies for not having a better response at this time, but we'll get it cleared up!
Hi Cheryl, just to follow on from Greg's comment earlier, our team is currently working on restoring functionality for the usage of custom ports with ZCLI and ZAT as the final step in our resolution of this issue. I'll be sure to update this thread once resolved.
Having issues with ZAT and theme preview, so I am not sure if these are related. Loading *.js and *.css files fail due failed preflight requests, which I was not expecting at all. I am using the standard port only. I did not recognize any specific change or update in the environment. Schedule vise these problems occurred with same time as for others, and in my case, I still have problems with the standard port.
Is the standard port working fine for others now?
I just wanted to update this thread to let you know that support for custom ports when previewing apps using ZAT and ZCLI has been restored across Zendesk Support, Chat & Sell. Appreciate your patience while we worked through this.
Arno, in relation to any issues with theme preview - this would be unrelated to the issues experienced by others in this thread. I would recommend reaching back out to our support team and reporting the issue if this continues to be a problem for you
Thanks for the update. Was able to solve my problem. By default preview was listening to:
2023-02-13 21:22:51 +0200 Thin web server (v1.8.1 codename Infinite Smoothie)
2023-02-13 21:22:51 +0200 Maximum connections set to 1024
2023-02-13 21:22:51 +0200 Listening on 0.0.0.0:4567, CTRL+C to stop
Changed ip address to local host (127.0.0.1), and after that it worked fine again, so starting preview with binding:
zat theme preview --bind 127.0.0.1
Could be just related to my environment (Windows+Ubuntu). Posting this here just in case someone has similar problems.
Please sign in to leave a comment.