Repository navigation
Conversation
o-ba
left a comment
There was a problem hiding this comment.
Hey @foppelfb and thanks a lot for working on this!
The use case makes total sense, and I'd like to get it in. But I ran into a few things with the current approach that I don't think we can fix with small tweaks.
The main problem is that setting the client on ProviderConfiguration from a middleware doesn't reliably reach the request:
-
The adapter caches the platform per configuration, so whichever call creates it first wins. If the connection check or the grading judge happens to run first in a process, your middleware's client is never used.
-
Fallback providers, smart routing and auto model switch all work with their own
ProviderConfigurationinstances, which don't carry the client. So the retry after a timeout, probably the case you care about most, would run with the default timeout again.
I'm also not too happy about having a Symfony type on ProviderConfiguration. AiM doesn't require symfony/http-client-contracts, and I'd rather not add that dependency for everyone just because Symfony AI is optional.
What do you think about going with your "Alternative 1" instead? A PSR-14 event in SymfonyAiPlatformAdapter, fired when the platform is built, with the configuration and a settable client. It runs exactly where the client matters, it covers fallbacks and rerouting automatically, and the Symfony types stay in the Symfony AI part of the code.
A few smaller things:
- Only dispatch the event (and pass
httpClient) if the bridge factory actually declares that parameter; we already reflectendpointandapiKeythe same way. - Since the platform is cached per configuration, the event fires once per provider record. Worth a sentence in the docs so nobody expects per-request control.
- A test that goes through the adapter would be great: a listener sets a client, and the factory receives it.
Tasks:
Resolves: #33
Releases: main