GraphQL connected_circuit_termination does not return circuit termination in some cases

[PhillSimonds]

Environment

• Python version: 3.9.7
• Nautobot version: 1.2.8

Steps to Reproduce

1. Create a circuit
2. Attach the circuit to a device on one side
3. Attach the circuit to a different device on the other side
4. Execute the following graphQL query for one of the interfaces

query ($device: [String!], $interface: [String!]) {
  devices(name: $device) {
    name
    interfaces(name: $interface) {
      connected_circuit_termination {
        circuit {
          id
          }
      }
   }
}

Expected Behavior

I expected to acquire the circuit ID for the circuit used to connect the two device interfaces together.

Observed Behavior

The circuit termination comes back as null

{
  "data": {
    "devices": [
      {
        "name": "er01.lab01",
        "interfaces": [
          {
            "name": "HundredGigE0/0/0/3",
            "connected_circuit_termination": null,
          }
        ]
      }
    ]
  }
}

It looks like the gql query uses the interface's connected_endpoint attribute and checks to see if it is a CircuitTermination in order to derive whether or not a circuit is attached. In cases where a circuit is attached to an interface on both sides of the circuit, the connected_endpoint comes back as the remote device's interface rather than the CircuitTermination of the attached circuit. Thus the gql query therefore returns null because the connected endpoint is not a CircuitTermination, even though there is a CircuitTermination connected to the interface.

https://github.com/nautobot/nautobot/blob/develop/nautobot/dcim/graphql/mixins.py#L20

[glennmatthews]

Thanks for the report!

I think this is working as intended due to #104. The connected_* GraphQL fields correspond to the PathEndpoint.connected_endpoint field, which is the endpoint of a CablePath, not to the CableTermination._cable_peer field that represents the two endpoints of given Cable. Because the CablePath continues from the first device interface through the circuit to the second device's interface, it's expected that connected_circuit_termination will be null in the GraphQL response because the interface's CablePath doesn't terminate to a CircuitTermination; instead you should be able to check and see that connected_interface is non-null in this case and describes the interface on the second device.

[PhillSimonds]

Ack. Would it be possible/beneficial to add a circuit_termination GraphQL field so that we automatically return the circuit attached to the interface?

We could alternatively acquire data from the cable objects attached to the interface in order to determine that, but in that event the client has to implement logic to understand which side is the circuit termination and therefore which side to look at circuit properties for. There are two problems I see with using this approach:

1. It requires added complexity on the user side. The implementation I'm currently using to query the data is implemented by a tool that uses a JMESPath query. Writing that kind of if/else logic into a JMESPath query may be quite cumbersome (if it's even possible).
2. I can't actually currently use a gql query to get the circuit termination object data on the other end of a cable. I can only get the termination_[a|b]_id and termination[a|b]_type right now.

[PhillSimonds]

Another thought. If we did add the circuit_termination GraphQL field, then we have connected_circuit_termination and circuit_termination. There's a bit of overlap there and the difference is not easy to intuit. I see three options there.

1. remove connected_circuit_termination in favor of circuit_termination
2. keep both
3. update connected_circuit_termination so it returns the circuit_termination object

I think we've ruled 3 out, not sure what the best option is between 1 and 2 (if we do want to implement this query).