Whenever gqlgen runs, it almost randomly picks whether it will use interface{} or any in some generated code scenarios. Even though both interface{} and any will function the same, the inconsistency plays havoc with CI tests, generates spurious differences, and is frustrating.

Per #3414, specifically, this comment offers some advice on attempting to address the root cause of this issue without the simplistic find-and-replace hacks we have been using up to this point.

Rob Findley on the Gopher's slack:

When we added any, and updated all the standard library APIs to use it, we found it distracting that error messages would say e.g. fmt.Printf(string, ...interface{}) when the documentation says fmt.Printf(string, ...any). On the other hand it, it was equally confusing to print any when the signature uses interface{}. any is an alias for interface{}, of course, but in 1.18 when it was added go/types effectively erased aliases, and the only way to preserve the identity of any was to use a distinguished pointer for its underlying type.
Now, in Go 1.23 we actually use a types.Alias type, so that alias relationships are preserved during type checking, and things are simpler.
In order to advise on your bug, I'd need to know more. How are the types being produced? (is it by the type checker, or by an importer)? Which Go toolchain are you using? Do you have a repro?
This is because there are any number of things that could erase the identity of any. AFAIK we've been careful to preserve it during type checking and importing.

Signed-off-by: Steve Coffman steve@khanacademy.org