VanKhanhAnny opened a new issue, #1076: URL: https://github.com/apache/incubator-seata-go/issues/1076
### ✅ Verification Checklist - [x] 🔍 I have searched the [existing issues](https://github.com/apache/incubator-seata-go/issues) and confirmed this is not a duplicate - [x] 🛠️ I am willing to try to fix this bug myself. ### 🚀 Go Version 1.24.4 ### 📦 Seata-go Version master (local checkout) ### 💾 Operating System 🪟 Windows ### 📝 Bug Description This looks like a registry-initialization bug in the discovery subsystem. In `pkg/discovery/init.go`, `InitRegistry(...)` accepts multiple registry types in its switch, including `nacos`, `eureka`, `redis`, `zk`, `consul`, and `sofa`. However, only `file` and `etcd` currently instantiate a concrete `RegistryService`. For the unimplemented types, `InitRegistry(...)` does not return an error and still assigns `registryServiceInstance = registryService`, where `registryService` was never initialized. Related registry issues/PRs appear to focus on implementing adapters or adding config support. This report is different: it is about the current initialization path not failing fast when a configured registry type is recognized by name but not actually implemented yet. Relevant code areas: - `pkg/discovery/init.go` - `pkg/discovery/base.go` - `pkg/discovery/nacos.go` - `pkg/discovery/zk.go` - `pkg/discovery/consul.go` - `pkg/discovery/redis.go` - `pkg/discovery/eureka.go` - `pkg/discovery/sofa.go` - `pkg/remoting/getty/session_manager.go` This report is based on code inspection. I am not claiming a full end-to-end runtime reproduction or observed runtime logs. ### 🔄 Steps to Reproduce 1. Open `pkg/discovery/init.go`. 2. Inspect `InitRegistry(serviceConfig *ServiceConfig, registryConfig *RegistryConfig)`. 3. Observe that the switch includes: - `file` - `etcd` - `nacos` - `eureka` - `redis` - `zk` - `consul` - `sofa` 4. Observe that only `file` and `etcd` actually initialize a concrete `RegistryService`. 5. Open the unimplemented registry files such as: - `pkg/discovery/nacos.go` - `pkg/discovery/zk.go` - `pkg/discovery/consul.go` - `pkg/discovery/redis.go` - `pkg/discovery/eureka.go` - `pkg/discovery/sofa.go` 6. Observe that these files are still stubbed with `panic("implement me")`. 7. Open `pkg/remoting/getty/session_manager.go` and inspect the discovery lookup path in `getAvailServerList()`, which calls `discovery.GetRegistry().Lookup(...)`. Based on the current control flow, a configured registry type such as `nacos` or `zk` appears to be accepted by `InitRegistry(...)` without failing fast, even though the backend is not actually initialized. ### ✅ Expected Behavior If a configured registry type is not implemented yet, `InitRegistry(...)` should fail fast with a clear unsupported or unimplemented error. The initialization behavior should make the current support boundary explicit instead of accepting the registry type name and proceeding with an unusable registry state. ### ❌ Actual Behavior Based on direct code inspection, `InitRegistry(...)` accepts several built-in registry type names without creating a concrete `RegistryService` and without returning an error for those cases. It then assigns `registryServiceInstance = registryService`, even though `registryService` was not initialized for those types. The later discovery path in `pkg/remoting/getty/session_manager.go` immediately calls `discovery.GetRegistry().Lookup(...)`, so the current behavior appears unsafe for configured-but-unimplemented registry backends. ### 💡 Possible Solution Handle unimplemented registry types explicitly in `pkg/discovery/init.go` and return a clear error instead of leaving `registryServiceInstance` unset or nil. It would also help to add test coverage in `pkg/discovery/init_test.go` for currently recognized but unimplemented types such as `nacos`, `zk`, `consul`, `redis`, `eureka`, and `sofa`. -- 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]
