Datagrepper returns no results when querying for WMCO index images using fbc_fragment=release-4-19, while the same approach works correctly for 4-18.
The automation for selecting the latest Windows Machine Config Operator (WMCO) index image relies on filtering fbc_fragment tags via datagrepper. While querying for 4-18 works as expected, using the tag release-4-19 results in no output, despite the presence of known working IIBs.
This issue breaks WMCO automation and upgrade workflows for OpenShift 4.19 clusters.
 

    4.19 WMCO 10.19

    100%

    1.Set the time range:
fbc_tag="release-4-19"
start=$(date -d '30 days ago' +%s)
end=$(date +%s)

    2. Run the query:
curl -s "https://datagrepper.engineering.redhat.com/raw?topic=/topic/VirtualTopic.eng.iib.build.state&contains=windows-machine-conf-tenant&start=${start}&end=${end}" \
  | jq -r --arg tag "$fbc_tag" '
      .raw_messages[]
      | select(.msg.index_image_resolved != null and .msg.state == "complete")
      | select(.msg.index_image_resolved | startswith("registry-proxy.engineering.redhat.com"))
      | select(.msg.fbc_fragment | contains($tag))
      | "\(.timestamp) \(.msg.index_image_resolved) \(.msg.fbc_fragment)"'

    3. 
    

    A WMCO index image is returned, for example: registry-proxy.engineering.redhat.com/rh-osbs/iib@sha256:<digest>

    Works as expected on 4.18
fbc_tag="4-18" 
same query
registry-proxy.engineering.redhat.com/rh-osbs/iib@sha256:147c4c281a9509265423901a4558389a74b0d7e847d4500986e255131c721312

Impact:
Automated workflows that rely on dynamic discovery of WMCO index images for OCP 4.19 cannot function, leading to:
WMCO not being installed on fresh 4.19 clusters
Upgrade flows failing when relying on Konflux-index-based IDMS