Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Preserve rewrite Config to Opt-out of breaking single-file resolver always rewriting #3359

Merged
merged 1 commit into from
Nov 9, 2024

Conversation

StevenACoffman
Copy link
Collaborator

@StevenACoffman StevenACoffman commented Nov 8, 2024

See issue #3321 - users of gqlgen who upgraded to v0.17.50 and had configured a layout of "single-file" for resolvers started to find their existing resolvers suddenly overwritten when re-generating models for schema changes. This change in behavior broke things for a number of people (sorry). It was intended that this behavior would be opt-in with a configuration option, but that was omitted.

This behavior change was introduced in #3243 to solve #3205 so that Bazel integration was possible (AFAICT Bazel needs a layout of "single-file" but needs to regenerate the resolver every time the schema updates). This was necessary for a big rewrite of the Apollo Federation code contributed by an organizations that use Bazel.

This PR adds a configuration option preserve_resolver that if explicitly set to true will not avoid rewriting the resolver when gqlgen is run.

This means that people who want the v0.17.49 single-file resolver behavior will need to add preserve_resolver: true to their gqlgen.yaml config.

I'm actively soliciting feedback as to whether it should be opt-out with preserve_resolver vs opt-in with rewrite_resolver.

What has always been awkward (and is of special concern in this PR) is that the gqlgen resolver rewrite/preserve behavior for a configured layout of follow-schema is the opposite of the old v0.17.49 single-file.

If we made the config option rewrite_resolver so that the default was false, then that implies that everyone who uses follow-schema layout needs to add rewrite_resolver: true or silently fail to update their resolvers.

I've already been very disruptive to one set of gqlgen users, I would prefer not to "fix it" by inflicting similar disruption to others, but I'm open to feedback or alternatives.


Note, I also fixed the annoying test regeneration cycle in a few tests so those tests begin by resetting to a good state before running.

Signed-off-by: Steve Coffman [email protected]

@StevenACoffman StevenACoffman marked this pull request as draft November 8, 2024 19:37
@StevenACoffman StevenACoffman added the help wanted Extra attention is needed label Nov 8, 2024
@StevenACoffman StevenACoffman force-pushed the single_file_rewrite_disable branch 3 times, most recently from 99f0354 to 1fff825 Compare November 8, 2024 22:00
@coveralls
Copy link

coveralls commented Nov 8, 2024

Coverage Status

coverage: 59.422% (-0.02%) from 59.44%
when pulling 75966dc on single_file_rewrite_disable
into b207ed5 on master.

@StevenACoffman StevenACoffman marked this pull request as ready for review November 8, 2024 22:09
@StevenACoffman StevenACoffman removed the help wanted Extra attention is needed label Nov 8, 2024
@StevenACoffman
Copy link
Collaborator Author

FYI @Vilsol @UnAfraid @JonasDoe

@JonasDoe
Copy link
Contributor

JonasDoe commented Nov 8, 2024

Wow, thanks for the fast fix!

To answer your question: personally, the only reason why I'ld favor to default preserve_resolver to true is that it feels more like a guarantee this behavior isn't deprecated and will remain fully supported in the future. But from what I understand after reading your remarks, there's no reason to assume it might get dropped. So I'ld be fine with defaulting the setting to false, either. 🤷‍♂️

But if I understand correctly the big question you're asking is: how many ppl. have already updated their gqlgen since September, and how many haven't yet and might be startled by the changed behavior in the future? I'ld think most users don't update gqlgen avidly - you don't change your schemas that often, if even if you did, you wouldn't necessarily update this library each time. I might be wrong here, of course.

As a consolation: gqlgen still hasn't reached v1 (and I doubt it ever will), so technially you're free to break the api with every release. ;)

@argoyle
Copy link

argoyle commented Nov 8, 2024

I run Renovate on all my repositories to keep all dependencies up to date at all time (and recommend everyone else to do the same). Just to show the other side of the argument. 😁

@StevenACoffman
Copy link
Collaborator Author

StevenACoffman commented Nov 9, 2024

We use gopkg.in/yaml.v3 to unmarshal/deserialize/decode from the yaml config to the resolver config struct so we cannot easily have gqlgen yaml configs that are missing any value for preserve_resolver default to true, as the zero value for a boolean is false.

There are 4,513 public repositories that import gqlgen and of the ones that appear actively maintained (commits in the last year) and use single-file layout, the majority have already updated to v0.17.50 or beyond.

I can't think of any way to get insight into private repository gqlgen version update information.

So it looks to me like if I flipped the single-file resolver rewrite back to the preserving behavior of v0.17.49 I would just make more trouble for most people who have already moved on.

BTW, there are 598 public repositories that have upgraded to v0.17.5x according to this: https://github.com/search?q=%22github.com%2F99designs%2Fgqlgen+v0.17.5%22&type=code

Based on that and the feedback above, I'm going to try merging this PR as is, cut a release, and update the v0.17.50 release notes. Hopefully we can advertise this workaround to the break better for anyone who is late to updating.

Again, sorry for all the trouble. Thanks for remaining engaged and bringing it to my attention.

@StevenACoffman StevenACoffman merged commit b332879 into master Nov 9, 2024
17 of 18 checks passed
@StevenACoffman StevenACoffman deleted the single_file_rewrite_disable branch November 9, 2024 00:44
@StevenACoffman StevenACoffman changed the title Config option to preserve single file resolvers instead of always rewriting Add Preserve rewrite Config to Opt-out of breaking single-file resolver always rewriting Nov 9, 2024
@StevenACoffman
Copy link
Collaborator Author

Fixes #3321 as best it can be fixed

@JonasDoe
Copy link
Contributor

JonasDoe commented Nov 9, 2024

I run Renovate on all my repositories to keep all dependencies up to date at all time (and recommend everyone else to do the same). Just to show the other side of the argument. 😁

Yeah, the three of us who were posting in this issue probably belong to this other side. ;)

Regarding default values: I think I was just a bit sloppy on responding. It would have been rewrite_resolver: false instead of preserve_resolver: true then ofc.

This quey is interesting! But if you go the versions backwards here, it looks like only a minority of the public repos was actually updated.

Anyway, every solution is a good one, thank you again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants