Problem
In the DPU proxy (pkg/interceptors/dpuproxy/proxy.go), registering a unary RPC method as ForwardToDPU in defaultForwardableMethods is not sufficient to actually forward the method. The interceptor logic (UnaryInterceptor) does a hard-coded switch and requires that each forwardable method is implemented as a dedicated forwardXXXRequest function. Otherwise, requests will return:
Unimplemented: forwarding for method /gnoi.os.OS/Verify not yet implemented
This caused a gap recently addressed in PR #663, which had to implement forwardOSVerifyRequest and forwardOSActivateRequest for /gnoi.os.OS/Verify and /gnoi.os.OS/Activate. Previously, those methods were whitelisted but not actually usable.
Expected Behavior
Registering a unary method with ForwardToDPU should be sufficient to provide forwarding, without having to add a per-method handler for each one.
Actual Behavior
A dedicated forwarding function and manual case statement entry are required for each forwardable method, creating maintenance burden and risk of silent failure if omitted.
Impact
It's easy to break DPU proxy forwarding for new gNOI methods. This is an implementation design bug or a limitation of the current approach.
Proposed Solution
Consider refactoring the forwarding logic to allow generic forwarding of unary ForwardToDPU methods based on the registry, possibly using reflection or an interface assertion, so that registration alone suffices, and unhandled methods cannot be mistakenly listed.
Reference: PR #663
/cc @hdwhdw (issue author)
Problem
In the DPU proxy (
pkg/interceptors/dpuproxy/proxy.go), registering a unary RPC method asForwardToDPUindefaultForwardableMethodsis not sufficient to actually forward the method. The interceptor logic (UnaryInterceptor) does a hard-coded switch and requires that each forwardable method is implemented as a dedicatedforwardXXXRequestfunction. Otherwise, requests will return:This caused a gap recently addressed in PR #663, which had to implement
forwardOSVerifyRequestandforwardOSActivateRequestfor/gnoi.os.OS/Verifyand/gnoi.os.OS/Activate. Previously, those methods were whitelisted but not actually usable.Expected Behavior
Registering a unary method with
ForwardToDPUshould be sufficient to provide forwarding, without having to add a per-method handler for each one.Actual Behavior
A dedicated forwarding function and manual case statement entry are required for each forwardable method, creating maintenance burden and risk of silent failure if omitted.
Impact
It's easy to break DPU proxy forwarding for new gNOI methods. This is an implementation design bug or a limitation of the current approach.
Proposed Solution
Consider refactoring the forwarding logic to allow generic forwarding of unary
ForwardToDPUmethods based on the registry, possibly using reflection or an interface assertion, so that registration alone suffices, and unhandled methods cannot be mistakenly listed.Reference: PR #663
/cc @hdwhdw (issue author)