Q: How to fetch generated blocks from a given provisioner?

[BoboTiG]

Summary

I would like to use an efficient GraphQL query to fetch generated blocks from a given provisioner.

The current way I'm doing it is to fetch all blocks, and then filter on the block.header.generatorBlsPubkey value. It is almost OK today because there are not millions of created blocks; but it will become a problem soon enough.

Detailed Description

Here is the current "broad" query:

provisioner='PUBLIC_KEY'
curl 'http://127.0.0.1:8080/02/Chain' \
  --data-raw '{"topic": "gql", "data":"fragment BlockInfo on Block { header { height, generatorBlsPubkey } } query() { blocks(last: 10000) {...BlockInfo} }"}' | \
     jq ".[] | map(select(.header.generatorBlsPubkey == \"${provisioner}\"))"

Now, my question is: can this kind of modified query work? Maybe it's something that could be acheive already but I did not find the correct query:

curl 'http://127.0.0.1:8080/02/Chain' \
  -H 'Rusk-gqlvar-prov: PUBLIC_KEY' \
  --data-raw '{"topic": "gql", "data":"fragment BlockInfo on Block { header { height, generatorBlsPubkey } } query($prov: String!) { blocks(generatorBlsPubkey: $prov) {...BlockInfo} }"}'

This results in this error:

[{"locations":[{"column":102,"line":1}],"message":"Unknown argument \"generatorBlsPubkey\" on field \"blocks\" of type \"Query\"."}]

[sanderdms]

I currently ingest all data into a relational database and query it from there. I understand this doesn't directly answer your question, but could you share more about your use case? Depending on your needs, I might be able to work on providing trusted aggregation API endpoints or webhooks. -- Also can you specify what would be the required update frequency and how critical is API uptime for your case ?

[BoboTiG]

I am tracking my nodes rewards, so every hour or so I call a cronjob to fetch the number of generated blocks using the code shared in the description.
Thank you for your idea, but I would not like to use a third-party service. A normal GQL request would be so much better.

The current code works and will work for quite some time, but it is very inefficient for both the node, the ingestion script, the bandwith, etc.

[BoboTiG]

I went the other way finally: listening to the blockchain for accepted blocks events (using RUES).

[BoboTiG]

Update: I implemented pagined fetches in order to be able to get data from the genesis, see BoboTiG/dusk-monitor@0ca521b.

I am reopening the issue since having a way to filter blocks at the core level would be the best efficient.

Team, is it something that is already in your backlog? Is it something wanted?
I can give a hand, trying something given my rust skills (near to zero, but I already read a good part of the code, and I could hack something ugly haha). If you are OK, I could open a PR.