Unable to merge field selection in one resolver with selectionSet in another resolver

[onelittlenightmusic]

Thanks to #584, now we can set field selection in apiContext call. This is great because it solves #579.

But there might be some drawback.. I found an issue when applying newest GraphQL Mesh to my project.
I created a simple example here.

The first resolver returns a type PageviewTops. I used field selection in api call.

[1st resolver]

extend type Query {
        viewsOver500K(project: String!): PageviewTops
}

    async viewsOver500K(obj, _, { Wiki }, info) {
      const pageviewTops = await Wiki.api.getMetricsPageviewsTopProjectAccessYearMonthDay(
        {
          project: "en.wikipedia.org",
          access: "all-access",
          day: "31",
          month: "05",
          year: "2020"
        },{
          fields: {
            items: {
              articles: {
                views: true
              }
            }
          }
        });
      return pageviewTops;
    },

The second resolver is a query resolver topViewArticleName in PageviewTops type. This has selectionSet. I imagine the field selection in first resolver and the selectionSet in second resolver request different fields each other (first => view, second => article)

[2nd resolver]

      extend type PageviewTops {
        topViewArticleName: String
      }

  PageviewTops: {
    topViewArticleName: {
      resolve: async (obj, _, { Wiki }, info) => {
        return obj.items[0].articles[0].article;
      },
      selectionSet: `
      {
        items {
          articles {
            article
          }
        }
      }
      `
    }

My use case is that I call the first resolver at root level. And I call the second resolver under the returned type of first resolver.

  viewsOver500K(project: "en.wikipedia.com") { # First
    topViewArticleName # Second
    items {
      articles {
        views
        # not including the field `article` required in second resolver
      }
    }
  }

Then I have this result in which second resolver returns null. This is because selectionSet is not reflected.

{
  "data": {
    "viewsOver500K": {
      "topViewArticleName": null,
      "items": [
        {
          "articles": [
            {
              "views": 5440104
            },
..

To test effect of field selection, I removed field selection in first resolver like this.

[Arranged 1st resolver(removed field selection)]

    async viewsTop(obj, _, { Wiki }, info) {
      const pageviewTops = await Wiki.api.getMetricsPageviewsTopProjectAccessYearMonthDay(
        {
          project: "en.wikipedia.org",
          access: "all-access",
          day: "31",
          month: "05",
          year: "2020"
        });
      return pageviewTops;
    }

Then I got this result, which includes right value of second resolver. This shows selectionSet is reflected without field selection of first resolver.

{
  "data": {
    "viewsTop": {
      "topViewArticleName": "Main_Page",
      "items": [
        {
          "articles": [
            {
              "views": 5440104
            },

The main issue is that, once we use field selection, other resolvers cannot set selectionSet to the same objects. The same pattern is in my project here.

I try to summarize. Maybe these three field selections are related. Some intelligent merge mechanism will be required in this case.

query {
  first(): type A {
    second()
    otherfield1
    otherfield2
  }
}

[Field selections related to type A]

1. Field selection in first() resolver (this was solved in Ignore GraphQLResolveInfo if fields option is defined in in-context sdk #584)
2. User field selection (otherfield1, otherfield2)
3. selectionSet from second() to prepare resolver parameter obj (this issue's topic) --> there might be multiple resolvers with selectionSet..

@ardatan You suggested you were thinking some easier method to merge field selection... I wish your possible solution meets this issue as well. I did simple remediation at #579 in order to merge 1. and 2. but I found that was not sufficient...because 3. was not covered. Do you have any suggestion? Thank you.