GraphQL empty attribute list error - suddenly

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?

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

Thanks!

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 } } };
};

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
        }
      }
    }`;

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

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?

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

@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.