apache / apache/dubbo-go

[PROPOSAL] unify SPI lookup behavior before moving out extensions

Open
#3,257 0 comments 0 reactions 1 assignee Claimed by @zbchi View on GitHub
proposal
Dominant language
Go
Stars
5k
Forks
1k
Avg merge
3d 6h
Merged PRs (30d)
29

Description

### ⚠️ 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

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_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.