@Misko Its unfortunate that I didn’t have the other errors at the time of the initial ticket creation, however, if you have a closer look at my second comment on this thread, you can see there that the
Unexpected token I had been flagged there, so I had highlighted that there are many different error responses returning from your system. I assure you too that the
Unexpected token E has occurred many times in the past also. Which error it is that comes up is random so it was luck of the draw for what screenshots I could provide you really.
The errors in my latest comment had come from a build using the first API key that I provided above if that helps determine which data center that particular account is connected to?
As mentioned, its persistence is pretty random. For example, the second API key had a number of builds fired between the time you flagged a fix was in place and now, and we have only seen one failed build out of about 9 builds. The error that occurred in that build was:
The error that occurred about 12 hours ago using the first API key is actually the error you claim to have repaired:
As for capturing what the actual response is behind it, I would LOVE to as I’d like to see what it is for myself to know if there’s anything on our side we can do to prevent it, however, after much research, I don’t believe Gatsby logs the errors coming from GraphQL, or even what occurs during the node creation of the data. We are using your gatsby package
@builder.io/gatsby to create those nodes to use in these queries if that helps any? If you have any ideas on how and where we can somehow log whats happening behind this, I’m all ears - I’ve not found any way of doing so though.
Probably goes without saying, this is a pretty annoying problem. It is wasting clients build minutes, is unreliable in knowing whether changes can be pushed live in a timely manner, and the worst part is that its unpredictable - as mentioned, we can redeploy after an error and it works, or we have to redeploy 5-6 times before it will successfully go through (which is a strong indication that its not the code). Not ideal when clients have time-sensitive builds that need to happen and have to wait half a day sometimes before we get a successful build through. I’d find it hard to believe that we’re the only accounts affected by this also - if I’m honest.