DynClientBuilder broken? #1458

patonw · 2026-03-04T20:48:39Z

patonw
Mar 4, 2026

Has anyone been able to get DynClientBuilder working since it was deprecated in v0.25?

AnyClientVTable always fails to resolve the completion model. This doesn't seem like a valid use of downcast_ref (trait to trait). All the documentation and example I've seen indicates that it should cast to a concrete type. AnyClient only compiles because it's asking for references as the concrete target type.

... also, the factory registration uses the provider name, but all lookups use provider and model. There seems to be a conceptual disconnect here: The workaround would seem to knowing models with providers ahead of time to call register but that requires you to pass concrete providers to the generic params. If that's the intended way to use it, why does the the builder automatically register plain provider names in the first place?

main...patonw:rig:fix/dynclient

trying AnyClient as an enum wrapper around providers instead. Thoughts?

An alternative pattern could involve using the inventory crate to register factories for each provider. Haven't thought through exactly what that would look like yet, but it should allow decentralized registration, even across crates.

Also, gating it behind a non-default feature flag seems like the next step/an alternative to deprecation.

joshua-mo-143 · 2026-03-05T15:50:01Z

joshua-mo-143
Mar 5, 2026

Hi! Yeah it's been deprecated because the team has made a collective decision to not maintain DynClientBuilder anymore. We do need to get around to feature-gating/deleting it, but haven't done so yet as we've had to prioritise other things.

We had a lengthy internal discussion specifically on the state of DynClientBuilder, but you can basically find the rationale for deprecating below.

A large part of the issue is that originally there were quite a lot of other parts of the codebase that it was touching, so it was very difficult to remove. This made it very frustrating to update whenever we needed to do any kind of work that touched it at all, and a large part of Rig is that we want to enforce capabilities and provider errors at compile-time rather than basically just rawdogging the runtime and hoping nothing goes wrong. DynClientBuilder essentially went against the entire point of that and it was kind of self-defeating.

We tried to rework it, but eventually decided that due to the poor tradeoffs for maintaining it, it would be better instead to deprecate it. In lieu of this, we have an example showcasing enum dispatch which users are more than free to use and we also have an example in our Playbook that illustrates it.

It's pretty unlikely that this feature will come back in the main crate unfortunately, since it was basically causing a lot of unnecessary issues with the rest of the crate. Happy to link it as an official companion crate though if anyone wants to build it!

4 replies

patonw Mar 5, 2026
Author

I don't mind that it will be removed in the future because it's not worth maintaining, just that it's unusable, currently.

As for compile-time vs run-time, would using blanket implementations bounded by Capabiltiies still be burdensome? My attempt at it seems to be working. Trying to use a model in a capacity it doesn't support through dynclient still won't cause an error until runtime. However, Capabilities allows us to create disjoint implementations that make enum dispatch easier without needing to explicitly implement the Dyn* traits for every provider.

I haven't tried splitting it off into a separate crate, yet. What besides src/client/builder.rs should be moved over?