Repository navigation
[Feature] Remove the dead WalletExtension gRPC service and config #6931
Description
Summary
The WalletExtension gRPC service has been registered but not implemented since Odyssey-v3.7 (2020-03): all four of its RPCs return UNIMPLEMENTED. This proposal removes the unused Java implementation, the node.walletExtensionApi configuration item that controls it, and the service WalletExtension definition in api.proto. It also removes the messages that are no longer used without this service: AccountPaginated, TransactionList, TransactionListExtention, TimeMessage, and TimePaginatedMessage.
Problem
Motivation
java-tron still includes a gRPC service, a config switch, and a set of proto RPC definitions that do not work. The in-memory index that once supported these RPCs was removed long ago because it used too many node resources for the value it provided; transaction information by account address is now provided by TronGrid. The config name may make node operators think it controls whether a working API is exposed, while the proto definitions cause SDK code generators to create client stubs for methods that can never succeed.
Current State
- Proto definitions:
protocol/src/main/protos/api/api.protostill defines fourWalletExtensionRPCs, all of which takeAccountPaginated.GetTransactionsFromThisandGetTransactionsToThisreturnTransactionList; their*2versions returnTransactionListExtention. These RPCs are the only users of the three message types in any.protofile in the repository.TimePaginatedMessageand theTimeMessageit contains are also unused after their*ByTimestampRPCs were removed in Rm api #909. - Runtime behavior:
RpcApiService.WalletExtensionApiprovides no RPC implementation: it extendsWalletExtensionGrpc.WalletExtensionImplBasebut overrides none of its RPC methods, and its only private helper,transactionList2Extention(), has no callers. Every request therefore uses the generated default handler and returnsUNIMPLEMENTED. Registration does not change this behavior. The service is added only on a solidity node whennode.walletExtensionApi = true;reference.confsets the key tofalseby default, but the bundledframework/src/main/resources/config.confsets it totrue. The old HTTP endpoints were removed with the RPC implementations in Feature/multi_module meger to develop #2533, leaving only unused integration-test helpers.
Limitations or Risks
This does not add a new runtime risk. The main issue is unnecessary confusion. Node operators may think node.walletExtensionApi controls a working API, while generated SDKs still include methods that always return UNIMPLEMENTED. The remaining code and proto definitions also require maintenance.
Proposed Solution
Proposed Design
- Remove the Java implementation: Delete the
WalletExtensionApiclass, its registration branch inRpcApiService.addService(), and theWalletExtensionGrpcimport. - Delete the proto definitions: Remove
service WalletExtensionand its four RPCs fromapi.proto, together with the five messages listed above. - Remove the configuration item: Delete
node.walletExtensionApifromCommonParameter,NodeConfig,Args, and all bundled.conffiles. If the old key is still present in an operator config, log a removal warning at startup. - Clean up the remaining unused code: Remove
Util.printTransactionList()from main sources, whose only caller is its own unit test; remove the unused WalletExtension test code fromGrpcClient,WalletClient, andHttpMethed; and delete the getter/setter assertions for the removed parameter fromParameterTest.
Key Changes
- Modules:
framework,common,protocol, and related test code - API / Behavior Surface: The four
service WalletExtensionRPCs are no longer registered and gRPC reflection no longer lists the service.
Impact
The change has no performance effect other than registering one fewer service at startup. It makes the node configuration and code easier to understand and maintain: it removes a config item that looks like an API switch but does not control a working service, stops generating SDK stubs for methods that can never succeed, and removes unused code from about a dozen files.
Compatibility
-
Breaking Change: Yes
- Generated code: code generated from java-tron's
api.protoor thetronprotocol/protocolmirror that uses the removed definitions no longer compiles. Trident is not affected. wallet-cli has no impact now, since it compiles its ownapi.proto; when it updates its proto, it needs to clean up the related code as well, e.g.Utils.printTransactionList. node.disabledApi: on a solidity node withwalletExtensionApi = truethat listed one of these methods innode.disabledApi, the call returnedUNAVAILABLEand now returnsUNIMPLEMENTED.
- Generated code: code generated from java-tron's
-
Default Behavior Change: No.
-
Migration Required: Only for clients that use the removed definitions; no action is required for node operators. Existing
walletExtensionApientries are ignored with a startup warning.
Additional Notes
- Do you have ideas regarding implementation? Yes
- Are you willing to implement this feature? Yes
Activity
waynercheung commentedon Sep 2, 2026
Thanks @0xbigapple. I verified the analysis at commit
4a21592f95: the RPC implementations were removed in127cd78ad1and have returnedUNIMPLEMENTEDsince Odyssey-v3.7.I support removing the Java, config, and protobuf surfaces together as an explicit exception to the deprecation policy in #6921. The exception is reasonable here because the RPCs have been non-functional for six years and were already identified as deprecated in Core Devs Call 60. Please update #6921 to record this decision.
For the PR, please:
node.walletExtensionApiis present, since unknown config keys are otherwise ignored.protocoland wallet-cli cleanup, and add a regression test confirming the gRPC status remainsUNIMPLEMENTED.Although the runtime status code is unchanged, removing the proto definitions is still a generated-code compatibility break and changes the reflection surface, so the downstream work should be linked before merge.
No consensus impact; this can target the next regular release. Happy to review the PR.
0xbigapple commentedon Sep 2, 2026
@waynercheung Thanks for your detailed comments and suggestions. I’ll update the issue #6921 description accordingly.
waynercheung commentedon Sep 2, 2026
@0xbigapple Thanks for confirming. Please link the PR here once #6921 is updated; I’ll review it against the compatibility and downstream requirements above.
0xbigapple commentedon Oct 10, 2026
@waynercheung Downstream check for #6975 (default branch of each repository). None of the items below blocks the PR; all can follow after merge.
Affected
tronprotocol/protocol:api/api.protostill definesservice WalletExtensionand the removed messages; sync after merge.api.proto; when updating its proto, clean up the related code as well, e.g.Utils.printTransactionList.walletExtensionApiinconf/main_net_config.conf,conf/nile_net_config.conf,conf/private_net_config_{witness1,witness2,others}.conf, the stress-test config and the toolkit test config.walletExtensionApiinmain_net_config.conf,test_net_config.conf,private_net_config.conf.walletExtensionApi = true.The leftover config key only adds a startup warning after upgrade; nodes still start.
Not affected
response.protokeeps an unused copy ofTransactionList(no RPC or code references it), which can be dropped but breaks nothing.google.api.httpmappings; no change needed.waynercheung commentedon Oct 10, 2026
Thanks for the downstream audit. Agreed these are non-blocking follow-ups. Please open tracking issues/PRs and link them under "Follow up" in #6975. Coordinate the protocol sync and the config/docs updates with v4.8.3; this issue can be closed once the follow-ups are linked. The wallet-cli cleanup can accompany its adoption of the updated proto.
@317787106 Principle 2 and item 4 in #6921 still describe two-stage deprecation. Please update them before the v4.8.3 release to record the direct-removal exception and the target version, and link #6975 from item 4.