zbchi opened a new issue, #3257: URL: https://github.com/apache/dubbo-go/issues/3257
### ⚠️ Verification - [x] I have searched the [issues](https://github.com/apache/dubbo-go/issues) of this repository and believe that this is not a duplicate. ### ✨ Proposal Summary Before moving more extensions to dubbo-go-extensions, it be worth defining and adopting a unified SPI lookup contract for missing extensions. ### Background We are preparing to move more extension implementations out of dubbo-go into a separate repository, dubbo-go-extensions. As more features are provided by external modules plus blank imports, the framework behavior for “extension not registered” or “extension package not imported” becomes much more important than before. In the out-of-tree model, a missing extension is no longer just an internal development mistake. It becomes a normal integration scenario that should have a clear and predictable handling model. ### Current situation For the same kind of problem, “the requested extension is not registered”, different SPI entrypoints behave differently: some panic some return error some return (nil, false) some return nil directly, sometimes with only a warning log Before moving more extensions to dubbo-go-extensions, it may be worth defining and adopting a unified SPI lookup contract for missing extensions. A few examples: GetRegistry panics when the registry is not found GetFilter returns (nil, false) GetLoadbalance, GetProtocol, GetConfigurator, GetConfigReaders panic on miss GetCluster, GetConfigCenter, GetLogger, GetTpsLimiter return errors GetProxyFactory logs a warning and returns nil GetMetadataReportFactory and GetConfigPostProcessor return nil directly Even for SPI APIs that do not panic on miss, the contract is not always strong enough at call sites. For example, BuildInvokerChain ignores the boolean returned by GetFilter, which means a missing filter may still fail later in a less direct way. This becomes more important as implementations move out of tree. Common migration-time scenarios include: the user adds an extension dependency but forgets the blank import only part of the required extensions are imported an aggregate import package is missing or incomplete migration is partial, so some extensions are still in-tree while others are external ### 🛠️ Implementation Approach efining and adopting a unified SPI lookup contract ### 📚 Additional Context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
