GraphQL empty attribute list error - suddenly

šŸ†˜ Support
1

We have noticed that something has changed in the graphql query interpreter. Before, such a query string was legit:

query() {
id
}

But now this breaks the site, because of the empty parentheses, without attributes. Did you guys perform some gql upgrade? If so, do you know of other possibly ā€œbreakingā€ changes?

Is it possible to get heads up of changes like that?

2

hey @sharedcodingsans can you please share an actual query that was valid and itā€™s not anymore?

Thanks!

3

Sure. As you can see we have a categoryFilter variabe which may be empty of may contain a category filter. this is inserted into the allBlogPostsMeta section, into parentheses. But if itā€™s empty, we get an unresolved error that points to the closing parenthesis. This most definitely worked untilā€¦ i would say 2 weeks ago. And the code has not been modified for more than a month now.

const categoryFilter = currentCategory ? `filter: {category: {allIn: ${currentCategory}}},` : '';

return query($limit: IntType, $skip: IntType) { ${headerRecord} ${footerRecord} blog { ${SeoRecord} allCategoryLabel ${categoryRecord} ${pageIntroRecord} bottomBlocks { ${blockWithCardsRecord} ${workWithUsRecord} } } blogListMeta: _allBlogPostsMeta(${categoryFilter}) { count } blogList: allBlogPosts(${categoryFilter} first: $limit, skip: $skip, orderBy: date_DESC) { author { nickname } ${categoryRecord} date intro title slug mainImage { alt url } } };
};

4 
const categoryFilter = currentCategory ? `filter: {category: {allIn: ${currentCategory}}},` : '';

  return `query($limit: IntType, $skip: IntType) {
    ${headerRecord}
    ${footerRecord}
      blog {
        ${SeoRecord}
        allCategoryLabel
        ${categoryRecord}
        ${pageIntroRecord}
        bottomBlocks {
          ${blockWithCardsRecord}
          ${workWithUsRecord}
        }
      }
      blogListMeta: _allBlogPostsMeta(${categoryFilter}) {
        count
      }
      blogList: allBlogPosts(${categoryFilter} first: $limit, skip: $skip, orderBy: date_DESC) {
        author {
          nickname
        }
        ${categoryRecord}
        date
        intro
        title
        slug
        mainImage {
          alt
          url
        }
      }
    }`;
5

Did you guys have a chance to look at this? @mat_jack1

6

hey @sharedcodingsans sorry I was on holidays, Iā€™m back!

Regarding your issue, I think itā€™s related to something that was permitted before but wasnā€™t actually a valid syntax :frowning:

Have you thought about moving the parenthesis inside the ternary operator, so that you donā€™t print anything at all?

7

Yes, thatā€™s what we did and thatā€™s what I was suspecting as well. So the ticket was written to find out:

  • what changed (graphql engine upgrade?),
  • from-to which version so maybe I can look up if there might be other hidden breaking changes with this upgrade (breaking for us anyway)
  • also if it is possible to get some kind of heads up when main components of the dato infrastructure change / get upgraded

thx,
Krisz

8

@sharedcodingsans we did upgrade our GraphQL engine, yes. We performed one week of inspection on 50% of the total of queries made to the system (thatā€™s about 20M+ requests) to see if there was any different behavior between the old and the new version. For each of these inconsistencies, we logged the project IDs, the precise queries performed and the number of queries.

Apart from minor nuances in how errors are reported, we found three notable differences (all bugfixes to make our responses more compliant to GraphQL standard), including the one you encountered.

For two of these three inconsistencies ā€” not the one you experienced, unfortunately ā€” we managed to still keep the old behavior in place, and just respond with a X-DatoCMS-Warnings header for the foreseeable future. Unfortunately, for the third change (the one you experienced), we could not do that for technical reasons.

Less than 0.0001% of the queries (around 10 projects) had the ā€œempty attribute listā€ error, so we decided to contact every project owner personally via e-mail to inform them about the change, and we made sure the upgrade didnā€™t cause any problems.

We then decided it was a more than a statistically significant number to proceed with the upgrade.

All this is to say that we tried to do everything as seamless as possible, and in general we succeeded, but evidently, despite extensive testing, we missed a few cases. To date, after weeks from the engine upgrade, in addition to yours we have received a second complaint for the same issue.

Iā€™m very sorry about this, and weā€™ll try to adopt an even safer process next time.

9

Hi Verna,

Iā€™ve been on another project so itā€™s only now Iā€™m reading your answer. I can see that you guys are doing your best, thanks for going into the details and sharing this behind-the-curtain sneak peek into your processes :slight_smile:

These things happen, so no hard feelings from our side. Only one question: you write you contacted all the project owners where you could see such a query being run. Did we during this time not run such a query with empty attribute list, or the problem is more like you cannot tell from every project who was using this ā€œinconsistencyā€? After all, the code runs on Vercel so you couldnā€™t tell i presume.
The reason Iā€™m asking is if you did try to contact us and we did not receive your warning that needs attention. Otherwise, all is good and well, thanks for keeping your system up to date.

Best,
Krisz

10

No, we did not contact you, probably because you ended up in the top 50% of requests that were not analyzed! Thank you for your understanding!

1 Like