update PAPI and improve fellows-action

[josepot]

It fixes this issue, significantly simplifies the code-base, and improves its performance (by paralellizing the identity requests).

A few clarifications:

• Starting the 2 clients in parallel is preferable than starting them sequentially, and there is no performance overhead for doing so.
• I think that the issue that happened here, in fact has to do with this. However, that error shouldn't have happened... So, we are looking into that. We actually think that it's possible that the error being logged is actually masking an error with smoldot, but we haven't gotten to the bottom of that yet.
• We have put a lot of effort to make sure that the consumers of PAPI can parallelize their storage requests. The library internally handles the complexities of ensuring that if all the slots guaranteed by the JSON-RPC spec are taken, that the requests are queued optimally... So, please, use that feature and avoid making sequential requests for things that could be parallelized 🙂.
• The only thing that needs to be done inside the finally clause is to kill smoldot, because that will also effectively kill all the clients if they are still active.

[rzadp]

Looks good to me.

I don't understand one thing though:

Before, we had two smoldot.addChain() invocations - one for polkadot and one for polkadot_collectives.

Now, there is only one - for polkadot.

What's up with that?

[josepot]

Looks good to me.

I don't understand one thing though:

Before, we had two smoldot.addChain() invocations - one for polkadot and one for polkadot_collectives.

Now, there is only one - for polkadot.

What's up with that?

Well, as you can see, this is completely bogus. It's just adding a chain for the sake of it, which is not being used anywhere... 🤷

[rzadp]

It's just adding a chain for the sake of it

Yeah but you still have to add it so it can sync, right?

I took a look and see that smoldot.addChain exists inside getSmProvider, so it makes sense to me now.