Add better validation around matching response with request information

[fselmo]

What was wrong?

• Add better validation that the cached request information really matches the response we are trying to process. This is done by passing the actual response_id for the matching request once we go back through the middleware onion and the response is present. This area of the code hadn't been iterated on since some of the earlier commits in the building out of the provider. This is a very important and necessary improvement on id matching.

This resolves an issue reported on Discord where await asyncio.gather(one_request, second_request) was guessing the wrong request id for each request since they are basically being triggered / yielding to each other in a shared context.

Steps to reproduce

async def reproducible_example():
    async with AsyncWeb3.persistent_websocket(WebsocketProviderV2(PROVIDER_URI)) as w3:
        (
            latest,
            chain_id,
            block_num,
            pending,
            chain_id2,
            chain_id3,
            finalized,
            balance,
        ) = await asyncio.gather(
            w3.eth.get_block("latest"),
            w3.eth.chain_id,
            w3.eth.block_number,
            w3.eth.get_block("pending"),
            w3.eth.chain_id,
            w3.eth.chain_id,
            w3.eth.get_block("finalized"),
            w3.eth.get_balance("shaq.eth")
        )
        print(f"block num from latest block: {latest['number']}\n")
        print(f"chain_id: {chain_id}\n")
        print(f"block_num: {block_num}\n")
        print(f"block num from pending block: {pending['number']}\n")
        print(f"chain_id2: {chain_id2}\n")
        print(f"chain_id3: {chain_id3}\n")
        print(f"block num from finalized block: {finalized['number']}\n")
        print(f"balance: {balance}\n")

asyncio.run(reproducible_example())

Todo:

• Add entry to the release notes

Cute Animal Picture

[reedsa]

In the examples we were walking through earlier, I think there was a sticky point that some responses didnt appear to include an id. If that happens, generate_cache_key will raise. Should we swallow that exception and just skip the processors here instead?

[fselmo]

That's a good point. We could still return the raw response and try to not halt things here. I think passing in the response to this method would allow us to retrieve the id if it's there or debug log the response that doesn't have an id and keep moving.

[reedsa]

Yeah that sounds like it would work great!

[reedsa]

Lgtm