chore: revert GraphQL builder from 2.x to 1.x

[vsseixaso]

What problem is this solving?

GraphQL builder 2.x introduced strict variable coercion via a newer graphql-js runtime. Third-party store apps that cannot be updated are sending variables with types that don't exactly match the schema declarations (e.g. quantity: 1 as an integer where the schema expects String, seller: 1 as integer, geoCoordinates: [float, float] where [String] is expected, and category/document id as a string where Int is expected).

These mismatches cause hard GraphQLError validation failures before resolvers are even reached. From the collected error logs, we identified the following distribution:

Pattern	Percentage
quantity: 1 (Int) → expected String	~69.5%
seller: 1 (Int) → expected String	~13.6%
category id: "20" (String) → expected Int	~12.3%
geoCoordinates: [float] → expected [String]	~4.7%

Reverting to graphql@1.x restores the lenient coercion behaviour of the previous runtime. The node@7.x upgrade (Node 20, @vtex/api v7) introduced in #687 is kept — only the GraphQL builder version is reverted.

Note: The upgrade to GraphQL builder 2.x will be reintroduced in a separate PR, where the identified error scenarios will be properly handled.

How to test it?

Regression script (test-errors-regression.sh in repo root) sends the exact queries and variable shapes extracted from errors.csv and asserts HTTP 200 with no errors block.

Results against the linked workspace:

shipping: quantity=1 (Int) in variables — real query     PASS
shipping: quantity="1" (String) in variables             PASS
shipping: quantity=2 (Int)                               PASS
shipping: seller=1 (Int) in variables — real query       PASS
shipping: seller="1" (String) in variables               PASS
category: id="20" (String) in variables — real query     PASS
category: id="1000240" (String) in variables             PASS
category: id=1 (Int, control)                            PASS
shipping: geoCoordinates=[4.5578,51.9293] (Float)        PASS
shipping: geoCoordinates=[-43.17,-22.90] (Float BR)      PASS
shipping: literals inline (no variables)                 PASS
category: literal id=1 (no variables)                    PASS
brands: basic smoke                                      PASS
documents: pageSize="2" (String) in variables            PASS

RESULTS: 14 passed

Workspace

Screenshots or example usage:

Before (graphql@2.x) — error from production logs:

Variable "$items" got invalid value 1 at "items[0].quantity";
Expected type String. String cannot represent a non string value: 1

After (graphql@1.x) — same request:

HTTP 200 — data returned normally

Describe alternatives you've considered, if any.

• Custom scalars (FlexibleInt, FlexibleString, etc.): Implementing custom scalars that accept both types was explored. However, this changes the type names visible in the SDL, which breaks any client that declares variables with the original types (e.g. $id: Int fails against an argument now typed FlexibleInt). Since third-party apps cannot be updated, this approach would trade one class of breakage for another.
• Resolver-level casting: Casting in resolvers only runs after GraphQL validation passes. The errors happen during variable coercion, before resolvers are invoked, so this approach does not address the root cause.

Related to / Depends on

Reverts the GraphQL builder portion of #687.
Node builder upgrade (node@4.x → node@7.x) from #687 is not reverted.

Made with Cursor

[vtex-io-ci-cd]

Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖

Please select which version do you want to release:

• Patch (backwards-compatible bug fixes)

• Minor (backwards-compatible functionality)

• Major (incompatible API changes)

And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.

• No thanks, I would rather do it manually 😞

[vsseixaso]

@mendescamara, o GraphQL 2.x é mais rígido com tipos e acabou afetando alguns merchants que enviam valores no formato errado.

A ideia aqui é voltar pro builder 1.x por enquanto e tratar esses casos antes de subir de novo pro 2.x em outro PR.

[vmourac-vtex]

LGTM
Nice to have validated against all regressions!

[vtex-io-ci-cd]

Your PR has been merged! App is being published. 🚀
Version 2.175.0 → 2.175.1

After the publishing process has been completed (check #vtex-io-releases) and doing A/B tests with the new version, you can deploy your release by running:

vtex deploy vtex.store-graphql@2.175.1

After that your app will be updated on all accounts.

For more information on the deployment process check the docs. 📖