Don’t tell that to the masses that requested it!
2 Likes
I think the masses were hoping for something that had real status updates provided by Glowforge’s DevOps/NetOps teams.
3 Likes
I kept getting that message all day yesterday. The only files I could upload must have been created in something other than what I use, since they were files I’d gotten through the forum. Thanks for the PDF trick - I didn’t even think of that yesterday. I thought the only format the GF would recognize was the SVG. I’m running the file now from the pdf - when it finishes, I’m going to try uploading again, since it seems that the issue might be resolved.
If I remember correctly, the loudest yells for the status page came on some weekend where they hadn’t figured out how to scale up properly. And then another time when Google had some cloud devices down. Given the tight-lipped philosophy around bug lists/statuses, I don’t see real-time updates on bugs anytime soon. Though an acknowledgement of this type of issue that effectively breaks the eco-system for a potential majority of users doesn’t seem too much to ask.
3 Likes
I just got a reply to my support ticket asking me to try uploading again and let them know how it goes. I’ll do that once the current file finishes.
The (ironically) cloud based status service they are using will certainly work for those issues.
It also has the built in capability for that, they’re just not using it.
From the link:
The unfortunate reality about running a software business is you’re going to have downtime. When downtime happens, it’s important to communicate what the problem is and what parts of your service are affected.
The video below explains how our customers create incidents and update the status of their components to effectively communicate around downtime issues.
(emphasis in original)
3 Likes
Seems to be working again.
1 Like
I don’t think the history shows problems that were automatically detected. I think it only shows a history of “incidents” that were created by the team that is responding to them.
Since they haven’t created any incidents, there isn’t any history of them.
There are a couple of “test” incidents visible in the RSS feed, but that’s it.
My Christmas Bonus jab was not without a history.
I kept having to return and service an automated robotics pallet stacker. Almost every time it turned out that some inputs from their networking package for the assembly areas that they had upgraded to and were still learning was a culprit.
Garbage In Garbage Out.
After about the 8th after fact assessment meeting, where I had been trying to explain about it being a programming error not related to the equipment on contract, but kept getting rebuffed since they had electrical component failure that this would not explain, I got stopped as I was heading to the gate, and an explanation came to light.
The guy told me that ‘computer errors’ directly affected the programming staffs Bonus. So there was Never going to be a programming error. He said they themselves just changed electrical components and other elements until the programming got fixed, then went on about their day. It always was an ‘electrical issue’ or ‘operator failure’, never a ‘programming error’.
So, from then on it was an ‘unidentified error’ and I just collected my charge fees and moved on also.
What he said made sense, even if it was stupid, but you have to question a system that allows this malarkey to survive.
2 Likes
I’m now back to ‘normal’ again.
Thank you.
Exactly ^^. It’s one thing for the community to graciously scramble and find a quick fix for people who need to get work done now. It’s very appreciated and a savior for those struggling. I’m sure GF appreciates the community doing their detective work for them as well, but support should not remain silent when there’s an issue on their end. Especially once users speak up in the forum and it’s obvious it’s not an individual user issue, support should have more input than a final, “it’s fixed now”.
GF knew it had made an update and either they caught that there were issues and failed they to acknowledge it to the community or they weren’t paying attention to the forum where it was apparent there was a problem. Individual users spent time dealing with it on their own and then the community spent time and effort trying to fix it becasue there was no acknowledgement from support it even existed. It was going down the same rabbit hole of “it’s a Corel issue or Affintiy issue” etc. with the fix being users having to adjust things on their end. While that’s a good short term work-around, it should not be the community goal of finding way to work around a problem. Simple regular posts from support acknowledging updates, issue and in-progress fixes would be so helpful and stop all the speculation and scrambling on our end. I expect and understand that crap happens with the updates, but remaining silent puts the burden on us and it’s getting a bit tiring.
8 Likes
The biggest failure here is that they didn’t respond to the community and secondly that it took them so long to work out a fix internally. The frontend is a modern React/Redux web application, knowing this along with the fact that they are using LaunchDarkly for feature testing, it’s not too difficult to make the assumption that they are also using Docker and Kubernetes. These tools all play nicely together and are very popular at the moment.
Having worked with these products for the last 3.5 years, I know that one of the main reasons for picking these tools is for ease of iteration and rollout. Implying they should have been able to: at worst rollback to the previous iteration with just a few commands, or failed forward with a hotfix for just a few more.
The most annoying part about this is that they appear to be using all the cool technologies, though forgot to implement the cool deployment strategies that go along with them. A simple percentage based rollout they would’ve detected these error messages coming in at which point they should have told their chatbot to “stop the presses” halting the release of broken code. On top of that, I’m hoping that for each of these “something terrible has happened exceptions” a user sees, the entire engineering team receives an email containing a full stack trace about what went wrong.
You cannot fault them too much, I only know a handful of companies that successfully implement the iterate fast model and it requires very hard to come by talent. The flip side of all this is that they could release 10x slower with 10x the safety guarantees. Though I would prefer to be down for a day with new features monthly. On top of that being down for a day still gives them a 97% uptime ratio for the month 
Sidebar: As an engineer that has worked for many companies with a “status page,” I would suggest that everyone stop relying on it. They are typically green until a support guy manually changes it. There are a few rare examples where companies had enough spare engineering effort that they could afford to make the status page extremely robust.
3 Likes
WELL…
What say @Rita ?
The second shift came on and replaced the buggy code!?
That fix lasted for two files.
Back to PDF it looks like…
@brokendrum We just tested the file you posted earlier and it’s working here. Could you share the file that you’re having trouble with now so we can take a look?
Thank you everyone for the feedback about this issue and how we’ve provided support. We are listening and looking at how to best provide support and the feedback is welcome.
Sure. Listed inside this zip as works + fails and both are same design I was trying, just to see what it looks like.
(Looks like the design may work, but going to redesign that ‘hurry up’ backdrop).
So → same file, as svg (fail) and pdf (loads)
Unicorn.zip (13.8 KB)
Customers are a lot more forgiving when they know what the issue is, so what changes were made that created this problem? I’m still miffed why my files that used to upload perfectly did not upload this past weekend.
I would rather have a company shutdown for a few hours (preferably in the middle of the night 
), make “upgrades”, instead of “sneaking them in” without sufficient testing.
Or, set up a test website and challenge us to break it by sending an assortment of files! Make it a game and it will be fun for everyone!!! And, avoid these kind of problems.
I know I sound like an idiot here, but when you are in the dark it is easy to do that.
Finally, all the people I had over this weekend for a GF party came away with “Hmmm, glad I didn’t get one of those.” Or, “Think I will wait.”
Still Love my GlowForge!!!
3 Likes
This sounds like a good idea to me. Glowforge’s internal testing seems rather inadequate (only using files generated by Illustrator and Inkscape from what I can tell).
1 Like
The one thing I am good at doing in life is breaking things, pretty much anything! 
It is usually a curse, but I am trying to find positive uses for this “talent”.
3 Likes