Generate static typename for element metadata key value pairs

[cornedor]

Element metadata key/value pairs generate different __typename's on each request. This behavior makes it very hard if you need to work with the type.
This behavior also causes issues with Apollo Router, causing it to return null instead of the value since the typename does not match the loaded super graph.

The response is always the same type, an object with two strings, name and value, so there is no need to generate separate type names on each request.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
100.0% Duplication on New Code

See analysis details on SonarCloud

[cornedor]

I have read the CLA Document and I hereby sign the CLA

[mattamon]

@fashxp do you have any idea why it is unique?

[fashxp]

@mattamon no, I have no idea.

[mattamon]

@fashxp okay thanks! So basically this would also be a breaking change no?
If someone somehow managed to deal with the unique keys, this would break the system if now it is the same.

[cornedor]

@mattamon Personally, I would not categorize this as a breaking change.

__typename is a type name, and should be static. The current behavior results in a breaking change for every request and does not follow the specs, since it is not possible to be used to determine Union types or cache keys.
This is the same as relying on a bug causing a 500 error, but that would not mean fixing it would result in a breaking change.

[fashxp]

I would agree with @cornedor.
Cannot imagine a constellation where someone could rely on that, can you?

[mattamon]

I would agree with @cornedor. Cannot imagine a constellation where someone could rely on that, can you?

I cannot, but there are some very creative solutions out there. :)
Then we should merge it. :)

[mattamon]

Thank you very much for clearing this up!