The matched port checker does not play well with the hub pattern. When it sees a pair (p1, p2) of matched ports, it expects each connection C with one end at p1 to have a unique instance I(C) at the other end, and it looks for a matching connection between p2 and I(C). This works fine for matched connections in a single physical deployment, but when matched connections cross a hub boundary everything is connected to a single hub instance, so the pattern doesn't work.
To fix this, we can allow explicitly unmatched connections, like this:
That way the command registration commands going through the hub can be manually numbered and explicitly unmatched, and the graph pattern specifier and matched numbering will fill in the rest.
In the future we can auto-generate the hub instances and the unmatched connections from matched, hub-free connections that span subtopologies, on each side of the network.
The matched port checker does not play well with the hub pattern. When it sees a pair (p1, p2) of matched ports, it expects each connection C with one end at p1 to have a unique instance I(C) at the other end, and it looks for a matching connection between p2 and I(C). This works fine for matched connections in a single physical deployment, but when matched connections cross a hub boundary everything is connected to a single hub instance, so the pattern doesn't work.
To fix this, we can allow explicitly unmatched connections, like this:
That way the command registration commands going through the hub can be manually numbered and explicitly unmatched, and the graph pattern specifier and matched numbering will fill in the rest.
In the future we can auto-generate the hub instances and the unmatched connections from matched, hub-free connections that span subtopologies, on each side of the network.