Allow fusion to merge interface and type of 2 subgraphs

Product

Hot Chocolate

Is your feature request related to a problem?

We have 2 subgraphs-services, maintained by 2 different teams (even inside different companies).

The first subgraph-service is a Product service, which tends to updated quite often.
The (simplified) subgraph looks like this:

interface Product {
  id: String!
  name: String!
}

type FoodProduct implements Product {
  id: String!
  name: String!
  expiryDate: String!
}

type ToolProduct implements Product {
  id: String!
  name: String!
  durabilityRating: Float!
}

type Query {
  products: [Product]
  productById(id: String!): Product
}

schema {
  query: Query
}

The second subgraph-service is a Stock service, which is updated rather seldom.
The (simplified) subgraph looks like this:

type Product {
  id: String!
  inStock: Int!
}

type Query {
  products: [Product]
  productById(id: String!): Product
}

schema {
  query: Query
}

When I right now run theses schemas through fusion, I get the following error:
Unhandled exception: System.InvalidCastException: Unable to cast object of type 'HotChocolate.Skimmed.ObjectType' to type 'HotChocolate.Skimmed.InterfaceType'.

Because on one graph Product is an Interface and the other graph it is a Type.

The solution you'd like

We will need to keep the second subgraph-service Stock service "dumb", which means that it only knows that there are generic products and keeps their stock count. Which means we want to decouple deployments of those 2 services, i.e. when adding on the Product service a new type, e.g.:

type MedicalProduct implements Product {
  id: String!
  name: String!
  requiresPrescription: Boolean!
}

The second Stock service should not require any updates and still be able to return the stock info for the new type as well.

With Apollo Federation we have achieved this so far by using the @interfaceObject directive (see here: https://www.apollographql.com/docs/federation/federated-types/interfaces/) on the second subgraph for Product.

Not sure what the proposed technical solution for fusion could be - maybe something in the schema.extensions.graphql that helps fusion to understand about this use case?

Reproduce the failure by running the Product and Stock schemas through Fusion, then inspect the schema.extensions.graphql approach and the handling of Product when one subgraph declares an interface and the other declares a type. Done means Fusion merges the schemas without the InvalidCastException, and a newly added subtype such as MedicalProduct can receive stock information without updating the Stock service.