Summary
Executing any SQL change ticket fails at session-creation stage. The scheduling log shows:
创建数据库连接失败，失败消息：Receive failed response from remote server. MsgContent is : Api fetchDsConfig failed, IndexOutOfBoundsException: Index 1 out of bounds for length 1
Request id is 6cc50579-2589-4f23-98bb-8d0b971d1fe6
Reproduced on Redis, PostgreSQL, and MySQL data sources, so it is data-source-agnostic — the failure happens before any database connection is opened.
Deployment: distributed, console + sidecar (two services connected over RSocket/TCP).
Root cause (with code references)
ConfigRService (backend/.../cgdm-api/.../console/configs/ConfigRService.java) declares two overloaded RPC methods:
DataSourceConfig fetchDsConfig(long dsId); // used by AutoExecJob (SQL ticket)
List<ConfigData> fetchDsConfig(String instanceId, List<String> names); // added for SSL lazy config, used by SslConfigManager
The RPC framework routes by method name only: interfaceFullName + "." + methodName (DmClientRSocketApiProxy#getMethodFullNameForSend), ignoring the signature. The two overloads therefore collide on the same route key. RSocketApiManager.scanAllApiAndRegister registers only one of them — which one wins depends on the JVM's Class.getMethods() return order (it also logs a "Register duplicated name method" warning).
On the console side, MainRequestDispatcher dispatches by the registered method's parameter count and then loops paramJsonValues.get(i). When the worker sends the 1-argument fetchDsConfig(dsId) but the console has the 2-argument variant registered, get(1) throws IndexOutOfBoundsException: Index 1 out of bounds for length 1.
Flow: AutoExecJob.run() (L129) → ConfigRService.fetchDsConfig(dsId) → console MainRequestDispatcher → IndexOutOfBoundsException → generateFailBackResult (Api fetchDsConfig failed, ...) → DmClientRSocketApiProxy (Receive failed response from remote server).
Why it looks intermittent / affects all datasources
- Which overload gets registered is JVM-order dependent, so the outcome can differ per restart and per node.
- The RPC exception happens before connection creation, so it is independent of the target database type.
- Standalone (
app.mode=embedded) deployments are unaffected because RSocket is skipped entirely in that mode — this bug only surfaces in distributed console + sidecar deployments.
Proposed fix (minimal)
Give the lazy config-value lookup a unique method name, e.g. fetchDsConfigByInstanceIdAndNames, updating ConfigRService, ConfigRServiceProvider, and the sidecar caller SslConfigManager. PR #330 aimed exactly at this but was closed without merging; its description records the same "argument-count mismatch caused by an overloaded RPC route" and verified that removing the overload eliminates the IndexOutOfBoundsException.
Additional context
Summary
Executing any SQL change ticket fails at session-creation stage. The scheduling log shows:
Reproduced on Redis, PostgreSQL, and MySQL data sources, so it is data-source-agnostic — the failure happens before any database connection is opened.
Deployment: distributed, console + sidecar (two services connected over RSocket/TCP).
Root cause (with code references)
ConfigRService(backend/.../cgdm-api/.../console/configs/ConfigRService.java) declares two overloaded RPC methods:The RPC framework routes by method name only:
interfaceFullName + "." + methodName(DmClientRSocketApiProxy#getMethodFullNameForSend), ignoring the signature. The two overloads therefore collide on the same route key.RSocketApiManager.scanAllApiAndRegisterregisters only one of them — which one wins depends on the JVM'sClass.getMethods()return order (it also logs a "Register duplicated name method" warning).On the console side,
MainRequestDispatcherdispatches by the registered method's parameter count and then loopsparamJsonValues.get(i). When the worker sends the 1-argumentfetchDsConfig(dsId)but the console has the 2-argument variant registered,get(1)throwsIndexOutOfBoundsException: Index 1 out of bounds for length 1.Flow:
AutoExecJob.run()(L129) →ConfigRService.fetchDsConfig(dsId)→ consoleMainRequestDispatcher→IndexOutOfBoundsException→generateFailBackResult(Api fetchDsConfig failed, ...) →DmClientRSocketApiProxy(Receive failed response from remote server).Why it looks intermittent / affects all datasources
app.mode=embedded) deployments are unaffected because RSocket is skipped entirely in that mode — this bug only surfaces in distributed console + sidecar deployments.Proposed fix (minimal)
Give the lazy config-value lookup a unique method name, e.g.
fetchDsConfigByInstanceIdAndNames, updatingConfigRService,ConfigRServiceProvider, and the sidecar callerSslConfigManager. PR #330 aimed exactly at this but was closed without merging; its description records the same "argument-count mismatch caused by an overloaded RPC route" and verified that removing the overload eliminates theIndexOutOfBoundsException.Additional context
cg.clouddm.main.version=4.2.2)MainRequestDispatcher, validateparamJsonValues.size() == parameters.lengthbefore binding and return a clear error instead ofIndexOutOfBoundsException.