bug: relationship to generic peer with wrong identifier leads to graphql error

[fatih-acar]

Component

API Server / GraphQL

Infrahub version

0.15.3

Current Behavior

When using the following schema:

# yaml-language-server: $schema=https://schema.infrahub.app/infrahub/schema/latest.json
---
version: '1.0'
generics:
  - name: Backup
    namespace: Cloud
    attributes:
      - name: created_at
        kind: DateTime
    relationships:
      - cardinality: one
        identifier: backup__instance
        name: instance
        optional: false
        kind: Attribute
        peer: CloudInstance
nodes:
  - name: SuperBackup
    namespace: Cloud
    inherit_from:
      - CloudBackup
    attributes:
      - name: updated_at
        kind: DateTime
  - name: Instance
    namespace: Cloud
    attributes:
      - name: created_at
        kind: DateTime
    relationships:
      - cardinality: many
        identifier: instance__backup
        name: backups
        optional: true
        peer: CloudSuperBackup

It is possible to delete a CloudInstance that has a SuperBackup linked to it.
When it is deleted and we try to list SuperBackup nodes, the executed graphql query fails.

This issue doesn't happen when using the schema below because the deletion of the CloudInstance is denied/prevented.

# yaml-language-server: $schema=https://schema.infrahub.app/infrahub/schema/latest.json
---
version: '1.0'
nodes:
  - name: Backup
    namespace: Cloud
    attributes:
      - name: created_at
        kind: DateTime
    relationships:
      - cardinality: one
        identifier: backup__instance
        name: instance
        optional: false
        kind: Attribute
        peer: CloudInstance
  - name: Instance
    namespace: Cloud
    attributes:
      - name: created_at
        kind: DateTime
    relationships:
      - cardinality: many
        identifier: instance__backup
        name: backups
        optional: true
        peer: CloudBackup

Expected Behavior

Deletion of the CloudInstance node should be prevented?

Steps to Reproduce

Use the above schema.
Create a CloudInstance.
Create a SuperBackup linked to this CloudInstance.
Delete the CloudInstance.
List SuperBackups.

Additional Information

No response