Multiple timeouts in GFUI Preparing Your Design

This evening I encountered a timeout in the GFUI in the “Preparing your design” step. I believe this issue was caused by an Illustrator file that had strokes with line-ends (arrow heads). The issue repeated twice. I then went back to Illustrator and did an “Outline Path” on those lines, and tried again. The design went through this time.

2 Likes

Yep, arrowheads are one of those “appearance but not actual path” things in Illustrator. (You took the correct action in outlining the stroke or expanding the appearance so that the actual path mirrored the appearance.)

Just FYI - dashed lines are the same in Illustrator - it’s an appearance, not actual dashes.

From everything I’ve seen over the last eight months, the GFUI looks for actual paths.

1 Like

Sure, it is totally reasonable for it to not render as shown, but the GFUI / back-end shouldn’t lock up.

BTW, I am not trying to be critical of your posts; I just don’t want some GF person to skim the thread, see your reply, and think the issue is resolved. This is a significant bug, and I just want to make sure it at least gets captured in their issue-tracking system.

4 Likes

It doesn’t lock up, it just refuses to process something that hasn’t been clearly laid out for it. (Okay potato, po-tah-to…) :smile:

If they were to process it as it appears to the interface, you would get a straight cut line, not an engraved line with an arrowhead on it. And then people would be aggravated that the machine didn’t do what they intended for it to do, instead of what they actually told it to do. And it would ruin a lot of material, and then folks would really be pissed.

As long as we understand what the interface sees, which is the actual construction paths, (not the appearance of the paths from half a dozen different drawing programs), we can design our files correctly. I know folks don’t believe it, but those times when the interface refuses to process a file are a good thing…they keep us from wasting material because there is something created incorrectly in our files.

And because there are so many different things that can cause issues, they don’t notify us specifically what it is yet. They might one day, (that would be nice), but they have got a whole lot of different input from a lot of different drawing programs, and they might not be able to. It would be a massive undertaking.

The refusal to process is keeping us from blowing it, and I appreciate that. Many, many times they’ve kept me from screwing something up because I forgot to check for overlays or convert something to paths that I should have.

It happens a lot less frequently as time goes on, and we learn what the interface is looking for. After several months doing this, I never get hit with the errors anymore. You won’t either after a little bit of time using it. :slightly_smiling_face:

But i do absolutely agree that it would be nice for beginner users to have a more specific error message or two if they can work out the most common ones. It would be a handy thing to have going forward…even if by the time they get them implemented, likely none of the early adopters are going to need them. :smile:

No, I am sorry, but you are 100% wrong. It sits there for a very long time before eventually giving a timeout message. This is very likely because something on the back end has either crashed or is on an infinite loop.

2 Likes

It really depends on the file I think - I’ve had some that took a long time to process…in excess of half an hour, and went on to finish.

Not to worry, they will still see your complaints. If there is something to be fixed on their end, I’m sure they’ll find it and fix it.

If you go back and re-read your initial problem description, you’ll see that when you changed what you did in the design, it processed quickly, and without a problem. If it was caught in a loop, it might have been because it was getting conflicting information as to what was wanted in the design.

Or I might be 100% wrong. :smile:
(A few folks around here seem to feel they have the right to tell me I am all the time, so it must be true.) :wink:

1 Like

They don’t have to be specific, and I agree that specificity is a big can of worms that can be addressed later.

In the meantime, they could create an error message that says something about a problem with your file, with a link to a help page that contains text similar to what folks like yourself have to post here, over and over and over… That would be a big improvement, as would be adjusting the brain in the cloud so that is searches for such issues as its first job.

There is no scenario where a long wait followed by a generic timeout error is the best user experience, or even a good one. I have to hope that such things are in place merely for expediency rather than as part of a UX philosophy.

This file seems to include features which are unsupported by the Glowforge. To learn more about how to prepare your artwork, visit the help center.

(If the job engine in the cloud does not return different error codes for different kinds of problems, then this goes from “should be easy” to “ask us again in 2019 because the two people that can change that are busy with other things.”)

3 Likes

Yeah, I like that better. It would at least give people a starting place, and not have us keep sitting around waiting, not knowing what the holdup is.

Right now, there are just too many things it “could” be. And we’re discovering new things all the time, as folks are submitting things from so many different source programs.

3 Likes

Yes, this is my point. Well-designed software should not crash or go into an infinite loop because it got inconsistent or bad data. This is particularly important for server-side software, which will be processing requests for multiple clients. To not do so is a bug, but even more importantly it’s a potential security hole; it opens the server up to denial-of-service attacks. Imagine if an attacker was able to write a malicious bit of code that sent a number of batches of “bad” files, each one causing a back-end processing thread to lock up or crash. The attacker could quickly consume all the server capacity.

Sorry if this is not obvious. It’s obvious to anyone who works on distributed software systems, but probably not at all obvious to someone who isn’t in the computer science business.

2 Likes

Nope, not even a little bit obvious, but if that is a security issue, I’m sure they will appreciate your pointing it out to them.

1 Like

Thanks for letting us know about this. I’m glad you were able to resolve the issue and finish your print.

I’ve recorded your feedback and shared it with the right people.

1 Like