GraphQL type name collision helper
If a graph fails to be created or updated, it is likely a type name collision has occurred. Manual intervention is required to resolve type name collisions before a new valid graph can be created and published.
The GraphQL type name collision helper allows a user to view whether the last attempt to generate a graph was successful or not. If it was not successful, it allows the user to view a list of fatal errors causing the failure. In cases where the failure was caused by a type name collision, the helper provides details of the conflicting content type schemas.
The helper can be used when a graph has never been built or when a graph has not been built after an update.
Using the GraphQL type name collision helperLink copied!
The functionality of the GraphQL type name collision helper is accessed using an HTTP API. Using the API requires authentication, as shown below:
Request URLLink copied!
For more information about finding the hub ID, head to the Finding the hub ID section.
AuthenticationLink copied!
The parameters and values needed for you to use the API are listed in the table below.
Parameter | Value |
---|---|
Username | Your username used to login to Amplience Dynamic Content. |
Password | Your password used to login to Amplience Dynamic Content |
Access Token URL | https://auth.amplience.net/oauth/token |
Auth Type | OAuth2 |
Grant Type | Resource Owner Password Credentials |
Client ID | B8F76643-CF4B-4A86-B03F-2F026B88693B Note that the Client ID will always be this ID. Do not use the Client ID associated with your chosen hub. |
Credentials | In Request Body Note that if you are using Insomnia to make a request, you may find the credentials section in the advanced options. |
There is no Client Secret
required for the usage of this API. Do not include one in your parameters.
Finding the hub IDLink copied!
hub ID
is the ID of the hub you're using for your queries. The hub ID can be found in the properties tab within the settings of your hub.
An example request is shown below:
Additional query parameterLink copied!
Include compilationSummary = true
in your query parameters to get a breakdown of all fatal errors. Without this additional parameter, you will only get a response that informs you whether the last attempted publish failed or passed.
Response formatLink copied!
Response | Description |
---|---|
generatedName | This describes the type name that the colliding types are trying to resolve to. |
conflictingTypes | Lists the two colliding content type schemas. |
createdDate | When the last attempted graph generation took place. |
code | The last attempt to generate the graph as a success or failure. |
errors | Lists fatal errors if status equals failure. |
detail | The detail for each error. |
message | A description of each error. |
conflictingTypes
lists two content type schemas. If more than two content type schemas conflict with each other, multiple error blocks will be repeated to ensure each schema that has a conflict on that type name is reported at least once.
Status codesLink copied!
Status code | Description |
---|---|
200 | The request has succeeded. |
400 | Bad Request. |
500 | Internal error |
524 | Request timeout |
ExamplesLink copied!
As this is a diagnostic HTTP API, it can be used with any API tool, such as Postman. For the following examples, we will be using Insomnia.
Identifying failed graphs with the helperLink copied!
In the GraphQL playground, you may receive a response like the below if a graph has never been built for your schema. The GraphQL type name collision helper can help us understand why.
Alternatively, if you make changes to a graph after it was built successfully, and the new changes are not being shown in the GraphQL playground, this can also be investigated using the GraphQL type name collision helper.
First, we retrieve an authorisation token using the required parameters, as shown below In Insomnia.
The response below is what we receive when we make our request without including compilationSummary = true
in our additional query parameters. We're informed the graph for the specified hub has failed to publish without specific details about which schemas caused a collision.
Identifying type name collisions with the helperLink copied!
Now we add the extra parameter of compilationSummary = true
to discover which schemas are causing a type name collision.
Example responseLink copied!
As shown in the response above, we can now see that our issue involves a banner schema and slot schema that have been given similar names.
The response message tells us the cause of the fatal error.
generatedName
is shown when a type name collision is the reason, and this describes the type name that the colliding types are trying to resolve to.conflictingTypes
lists the two colliding content type schemas.
Solving a type name collisionLink copied!
There are three ways to solve a type name collision:
- Archive the schemas causing the collision
- Add type name directives to your colliding types
- Use the skip directive
Archiving schemasLink copied!
One way to solve a type name collision is to use the Archive feature for colliding schemas. By Archiving a schema you remove it from the graph and remove any collisions it caused.
For more information about how Archiving works, please head to the Archiving a schema section.
Adding a type name directiveLink copied!
Another way to solve a type name collision is to add the graphql:typename
directive to your schemas. By adding this directive, you can manually define your own GraphQL type names for each of the colliding content types.
If a user includes the graphql:typename
directive within their schema, the value defined will be used to generate the GraphQL type name instead of the originally used type name, allowing for the type name collision to be solved.
For example, if we use the graphql:typename
directive to change the name of some colliding tutorial banner content types, we will notice that if we create some content using our newly named tutorial banner and then query for banners in the GraphQL playground, we get a response showing that the graph has been built.
Using the GraphQL type name collision helper, we also get a response informing us that the graph was successfully built.
For more information about how the graphql:typename
directive works, along with syntax rules for naming and examples, please head to the GraphQL type name overrides section.
Using the skip directiveLink copied!
The graphql:skip
directive can also be used to solve a collision. Adding this directive in your colliding content type schemas allows you to exclude them from the hub’s graph before it is built.
As the following schema snippet shows, the graphql:skip
directive accepts only boolean values:
For more information about how the graphql:skip
directive works, along with configuration options and accepted value formats, please head to the GraphQL type name overrides section.
Listing all hubs with the helperLink copied!
The GraphQL type name collision helper also allows you to list all the hubs you have access to. To make use of this feature, make a HTTP request to the below URL and enter your authentication details:
Key information like the ID, name, label, description, status and more of all the hubs you have access to will be included in your response. Along with the associated applications, and localization details.
Here is a short snippet of the JSON response: