AutoProvider has no attribute `_batching_context`

[antazoey]

What happened?

We can no longer use AutoProvider without getting an AttributeError for _batching_context

Code that produced the error

Full error output

Fill this section in if you know how this could or should be fixed

No response

web3 Version

No response

Python Version

No response

Operating System

No response

Output from pip freeze

[antazoey]

This is our current hack

    # TODO: Getting attribute error without this. Figure out why and do proper fix.
    class MockBatchingContext:
        def get(self, *args, **kwargs):
            return None

    provider._batching_context = MockBatchingContext()

[fselmo]

Hmm, I looked into this a bit and the AutoProvider itself doesn't hold any provider properties until it finds a provider and sets it. Those providers hold all these properties.

@antazoey do you have a code snippet of under what context this is happening? It seems like you haven't found a provider configuration if you're running into this.

I don't know that the right answer here is to properly super.__init__() the BaseProvider inside the AutoProvider.__init__() because it's itself a "shell" and not an actual provider. It just eventually delegates to one, if that makes sense.

Like none of our current auto provider batching tests are breaking at the moment but if I import from web3 import AutoProvider and instantiate it and purposefully call provider._batching_context it's not there. But again, it sort of shouldn't be there.

I can be convinced to init BaseProvider in the AutoProvider init but I'd like to know a bit more context under what circumstance this happens if possible.

Thoughts on the above?

[antazoey]

Ah, that context does help a bit. I tagged you on a couple spots in an Ape PR showing the hack in action (ApeWorX/ape#2627)

I don't really know.

[fselmo]

I think I see a possible cause. The AutoProvider doesn't set the active provider until a request is made or you enter a batching context. The code here is pretty ancient so I'm not sure what the original intention was but if I had to guess your code is somehow probing _batching_context without entering the batching context via w3.batch_requests() or you are calling it directly, expecting to check the batching state, before making any calls.

In this case the w3.provider is still an instance of the shell AutoProvider and hasn't had a "need" to get the "active" provider.

This is how it has always worked. I'm not entirely sure why it doesn't get the active provider in the __init__() of AutoProvider. It could call self._get_active_provider(use_cache=False) in the init which would set the active provider before a call is made.

Without any other context, I'm still inclined to leave it like this but knowing more now, I would think it's a much better UX to activate the provider in the init as I mentioned here. Perhaps @kclowes has a bit more context that I'm missing 👀

[fselmo]

@antazoey I think I found the issue. It's a proper bug. PR coming 👍🏼