We have another issue. Everywhere we copy the http client on the model from the provider (see screenshot above), we then won't be using the cache attributes to know whether this client belongs to the appropriate loop or not.

Ok, I've amended my commit with a new proposal, though I haven't tested it as much as the previous one. Now, this idea is to use a proxy object for the Transport, and decide on the real object only when we're sure we're in a valid async context.

What do you think ? Is that accesptable and should I work on that or do you see a flaw in that plan ?

Hm, I thought of a much cleaner solution: keeping transports in aweakrefs.WeakKeyDictionary[EventLoop, Transports]. This way, we keep the transports while the loop is alive and drop it when it's gone.

BUT the whole point is that transports keep a strong ref to the loop, so if we keep a strong ref to the transport, the loop's refcount is never going to go to zero 😭

I guess though we could remove any item from the dict where the loop is closed 🤔

New tentative (likely going to get complain for missing coverage).

I've kept the weakref just in case, but I've added code that will remove from the (weak) keys when the loops that are closed.

I think this should solve the issue. Happy to get some feedback before spending time adding missing tests. Also, if you want to take it from here, feel free :)

I tested changes with simple Streamlit app and Vertex AI.
Old issue with Closed Loops is gone.
Will try do some more tests and see how it works.
Chears for the fix.

I'll be leaving this PR for Pydiantic folks to whatever they want with them, but specifically for solving the Gemini issue, using the new GoogleModel should be a better alternative. Now the transport issue still needs to be solved at some point.

@ewjoachim sorry the lack of reply, I was not ignoring, I was talking it internally, because I actually expected unexpected issues with that implementation. 😔

I think the way we intend to move forward is to not do the cache we are doing, and have an async context manager to do the right thing in the Agent level.

I'll write more about it soon. But yeah, you can leave it to us. I'll get back to this soon.

Great !

Yeah, I too think the proper fix is to avoid creating any httpx session/transport/... until we're 100% sure we're in an async context, and then make sure we stop it when we leave the context. But yeah, either there's going to be change in the API and that's probably annoying, or there's going to be more profound change in the integration, but it doesn't make a lot of sense that this kind of change would be lead by a first time contributor, so yeah, it's probably better this way :)