Description of problem:

$ ./test.sh 
{
  "edges": [
    "4.13.23",
    "4.13.26",
    "4.13.25",
    "4.13.24"
  ],
  "conditionalEdges": [
    {
      "to": "4.13.25",
      "risks": [
        "AROBrokenDNSMasq"
      ]
    },
    {
      "to": "4.13.26",
      "risks": [
        "AROBrokenDNSMasq"
      ]
    }
  ]
}

That has 4.13.22 to 4.13.25 and 26 in both edges and conditionalEdges. But the conditional update enhancement says:

Edges with no matching blocks are unconditionally recommended, and will be included in edges. Edges with matching blocks are conditionally recommended, and will be included in conditionalEdges.

So Cincinnati should not be including 4.13.25 or 4.13.26 in edges as unconditionally-recommended 4.13.22 update targets.

Version-Release number of selected component (if applicable):

Seen in both https://api.openshift.com/api/upgrades_info/graph?arch=amd64&channel=stable-4.13 and https://api.stage.openshift.com/api/upgrades_info/graph?arch=amd64&channel=stable-4.13 , although I haven't looked up what commit they're currently running. I also haven't gone digging through history to try and figure out if/when this regressed.

How reproducible:

Every time.

Steps to Reproduce:

Run the attached script.

Actual results:

See a single version like 4.13.26 in both edges and conditionalEdges.

Expected results:

All target versions with update risk from that source version should only show up in conditionalEdges.

Additional info:

Fleet exposure is mitigated by the enhancement's:

The operator will log an error if the same target is included in both edges and conditionalEdges, but will prefer the c'onditionalEdges entry in that case.

but non-CVO clients may not be so careful.