refactor(router): inline 3 core resolver methods into ModelLookup#327
Conversation
Router.go ran three runtime type-assertions on `r.lookup` against the
optional interfaces `core.ProviderNameResolver`, `core.ProviderTypeNameResolver`,
and `core.ProviderNameTypeResolver`. *ModelRegistry already implements all
three; the assertions existed because the test `mockModelLookup` deliberately
omitted them to keep its surface small.
The optional-protocol pattern was being used as feature detection rather than
as real interface segregation: every production call site assumed the assertion
would succeed. Widening `core.ModelLookup` with the three methods removes the
indirection — `r.lookup.GetProviderName(...)` instead of
`if named, ok := r.lookup.(core.ProviderNameResolver); ok { named.GetProviderName(...) }`
— and the mock gains three trivial stub methods returning empty string,
matching how its missing data was already surfaced.
The three `core.*Resolver` interface types stay defined; they are still used
in 5 other places for provider-side type assertions on `core.Provider` (in
internal/server, internal/aliases, internal/gateway). Only the lookup-side
assertions are removed.
One side-effect cleanup in `Router.GetProviderTypeForName`: the
`modelWithProviderLister` iteration fallback became unreachable now that the
direct method is always available, and is removed. Behavior is strictly more
complete than the fallback — *ModelRegistry's direct method consults the
provider name/type maps, which include registered providers with zero
discovered models that the model-iteration fallback would have missed.
Test plan:
- All 25-ish tests using mockModelLookup compile and pass under -race.
- Full `go test ./...` clean across 56 packages.
- `*ModelRegistry` satisfies the widened interface (compile-time assertion at
registry_test.go:1865 still holds).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe PR centralizes provider lookup through the ChangesProvider Lookup Centralization
Possibly Related PRs
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR widens the
Confidence Score: 5/5Safe to merge. The change eliminates optional-interface indirection that was already assumed to succeed in every production call site, replacing it with direct method calls on a widened contract that the sole real implementor already satisfies. All three removed type-assertion blocks delegated to No files require special attention. External codebases that implement Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Router method called] --> B{Before PR}
B --> C[Type-assert r.lookup against optional interface]
C --> D{Assertion OK?}
D -- Yes --> E[Call method on lookup]
D -- No --> F[Return empty string or iterate models fallback]
A --> G{After PR}
G --> H[Call r.lookup method directly]
H --> I[ModelLookup contract guarantees method exists]
I --> J[Return result or empty string]
style F fill:#f9c,stroke:#c66
style J fill:#cfc,stroke:#6a6
Reviews (1): Last reviewed commit: "refactor(router): inline 3 core resolver..." | Re-trigger Greptile |
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Summary
Router.go ran three runtime type-assertions on
r.lookupagainst the optional interfacescore.ProviderNameResolver,core.ProviderTypeNameResolver, andcore.ProviderNameTypeResolver.*ModelRegistryalready implements all three; the assertions existed because the testmockModelLookupdeliberately omitted them to keep its surface small.That made the optional-protocol pattern act as feature detection rather than real interface segregation: every production call site assumed the assertion would succeed. This PR widens
core.ModelLookupwith the three methods and drops the indirection —r.lookup.GetProviderName(...)instead of theif okceremony — and the mock gains three trivial stub methods returning empty string, matching how its missing data was already surfaced.What does NOT change
The three
core.*Resolverinterface types stay defined. They are still used in 5 other places for provider-side type assertions oncore.Provider(ininternal/server/,internal/aliases/,internal/gateway/). Only the lookup-side assertions are removed.One side-effect cleanup
Router.GetProviderTypeForNamehad amodelWithProviderListeriteration fallback for the case where the lookup didn't implementcore.ProviderNameTypeResolver. With the direct method always available, that fallback became unreachable and is removed. Behavior is strictly more complete than the fallback:*ModelRegistry.GetProviderTypeForNameconsults theproviderNames/providerTypesmaps directly, which include registered providers with zero discovered models that the model-iteration fallback would have missed.Risk
core.ModelLookupgains 3 methods. Inside this repo it's a non-event — only impl is*ModelRegistry(already has them) and the test mock (now has stubs). Anyone outside the repo who implementedcore.ModelLookupfor their own purposes would need to add the 3 methods.mockModelLookupreturns empty string from all three new methods, matching the prior degraded behavior (the type-assertion path used to fail for the mock and fall through to the same""outcome).-race, plus the full./...suite (56 packages).Test plan
make test-race,make lint,go mod tidy— all green via pre-commit hooks.go test ./...clean across 56 packages.*ModelRegistrysatisfies the widened interface (compile-time assertion atregistry_test.go:1865still holds).🤖 Generated with Claude Code
Summary by CodeRabbit