[experimental] Should `responseProcessor` be async?

[steveluscher]

At the moment, an RPC API's requests can include a responseProcessor that transforms the server response before it reaches the caller in the client. We use this, for instance, to ‘upgrade’ number to bigint in the Solana RPC.

Is there a reason why you should be able to supply an async response processor here?

[buffalojoec]

Making this async would effectively make all response processor async right?

I think it might be OK considering we could stick an await Promise.all(..) inside and people would be none the wiser?

What would it look like if you supplied something that was synchronous, though? Do you have to do any weird wrangling or just supply it?

[mcintyre94]

I'd lean toward keeping it sync for now, because if we have an async processor here then there'll be a waterfall I think: async call to RPC -> async call to process

If possible it'd be better to independently fetch whatever else you need to process it, and then combine them after independently resolving the two async calls

That wouldn't work for use cases where you need to have the response from the RPC to process it - you'd need to do your own post-processing. I think that's probably fine though? If you're doing two async calls and they must be waterfalled, then something like this seems fine:

const { something } = await rpc.doSomething()
const result = await processThing(something)

I think that probably makes things clearer than having an async call to processThing buried in the RPC.

Pretty speculative without a concrete async use case though!