First draft: https://www.wikidata.org/wiki/User:Silvan_Heintze_(WMDE)/Wikibase_GraphQL. Maybe review comments can be left on the corresponding talk page.

Currently, there is no prometheus instance for the beta cluster, so this needs to be product verified either locally before deployment or on production after the deployment (or both)

• updated the Grafana board and moved the panel to third position from top (as it's really not that interesing)
• this is currently a little hard to verify with all skipped entity metrics being 0, but I think all types and formats should be covered now and show once per day
• will possibly need further adjustments once we actually have more skipped entitities than 0

In T405582#11515489, @Ifrahkhanyaree_WMDE wrote:

Question for dev chat/refinement:

1. Is the resolving happening currently without any notifications?

Thanks for the investigation and very comprehensible summary

          #
  #      ##
  #     # #
#####     #
  #       #
  #       #
        #####

waiting for approval by the SRE team

still waiting for T406497

see https://phabricator.wikimedia.org/T410487#11463456:

The mismatching edit summary decribed in T361444 shows when deleting a statement using wbremoveclaims and including an old revision ID as baserevid parameter in the request. The REST API specification for edit/delete requests does not include a baserevid parameter to indicate the revision of an entity to be edited or deleted. Instead, it relies on the HTTP standard of "Conditional Requests" as defined in RFC9110 to prevent edit conflicts.

resolved in https://integration.wikimedia.org/ci/job/wikibase-repo-php83/304/console

updating to docker-registry.wikimedia.org/repos/search-platform/cirrussearch-opensearch-image:v1.3.20-12 does fix the issue here locally

confirmed: I can reproduce this locally by running CirrusSearch\Maintenance\UpdateSearchIndexConfig --startOver and moving back to a commit prior to CirrusSearch: Make keyword fields actual opensearch keyword fields does fix it