You can find the factory resolver here:
node_modules/@strapi/plugin-graphql/server/services/builders/mutations/collection-type.js
There you see the actual actions ( find , findOne , create , update , and delete) are constructed here:
node_modules/@strapi/plugin-graphql/server/services/builders/resolvers/query.js
node_modules/@strapi/plugin-graphql/server/services/builders/resolvers/mutation.js
These actions make use of the new entityService API, thus indeed do not call the controller actions nor services, so it indeed looks like this is by design.
If you’d want to, looking at the factory resolvers could help you working out how to call the controller method inside a custom resolver. To me it feels a bit to hacky and prone to break on future updates.
The fact that core controllers and services seem completely irrelevant when using GraphQL is not reflected in the documentation, nor is the designated location where to handle its business logic. My guess would be the gql resolver. It’s just very strange to go to the trouble unifying the REST and GraphQL response format while at the same time completely diverging the 2 API flavors under the hood, not just for controllers, but services, policies and middleware as well. I dont have a problem with this per se, but I’d suggest adding a big ass toggle at the top of the documentation: REST or GraphQL.
I’d really appreciate a response from a Strapi developer on what the intended approach is when it comes to business logic within a GraphQL API. 