Connected trace fails to trace despite correct connectivity

[omar-marji]

I'm trying to run a connected trace on my Domain Network's Junction Object as shown in the image below. Within the attributes tree, it is clear that there is connectivity an an Edge Object but when I run a connected trace (with the result type set to Selection), only the starting point is selected and the trace does not propagate through the connected network.

What can I check in order to debug this issue? I checked for dirty areas, validated the network topology successfully and still no luck with the trace working.

The data shown in the images uses a UN data model built inhouse residing in an enterprise geodatabase and the data in the example is within a branch version (not posted to default). Other parts of this network trace correctly up to the last edge object before the element in question.

[RobertKrisher]

You can't trace using containment associations. Does the junction object have any connectivity associations?

[RamziQaqish]

Yes the trace is expecting the use of connectivity associations and not containment.

As you can see in the first image. Port 01 has Junction Edge connectivity to Fiber-01 and this is then connected to other elements in the network.

But when tracing Port 01 using a connected trace, it does not propagate through the network (even though I can see the connectivity association in the attribute tree)

[RobertKrisher]

Sorry, I missed the connectivity association in your screenshot. Can you show the attributes pane? Because the connectivity in your fiber network is all non-spatial, it will only select non-spatial objects. We can verify this using the attributes pane.

If you select the 'Include Containers' option it will select all the containers for your results, which will then select the containing lines/devices on the map.

[omar-marji]

Hi Robert,

Attached is a recording of the trace behavior.

Tracing the port and selecting the include containers, will only select the port and its parent containers.

Tracing the Fiber connected to the port selects the whole network connected it it correctly (except for the port in question).

Note: We are unable to reproduce this behavior consistently, i.e. sometimes we connect up the network and everything traces fine, other times (not sure how it happens) the trace gets stuck like this,  we then just delete the connectivity association and then recreate it and the trace work properly.

I kept this network so that we have one example were we can reproduce the issue.

[RobertKrisher · Accepted solution]

Please log a case with support, as that does not appear to be correct. If you disable and then enable the network topology, does the trace work correctly?

[omar-marji]

Yes, disabling and then re-enabling the topology did actually fix the trace.

What does this indicate? Should I still log this with support (I don't have any other reproducible case now though)?

[RobertKrisher]

oh, I should have recommended you make a backup of your data to repro with. It means that the connectivity association between the port and the fiber likely never got validated. This typically only happens when a connectivity association is created between non-locatable objects, but because both features were locatable (i.e. had a spatial container) I'm not sure how this would happen.