[Feature] Remove the dead WalletExtension gRPC service and config
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start with protocol/src/main/protos/api/api.proto and RpcApiService.WalletExtensionApi, then trace node.walletExtensionApi through CommonParameter, NodeConfig, Args, and the bundled .conf files. Review the named cleanup targets in Util, GrpcClient, WalletClient, HttpMethed, and ParameterTest. Done means the service, five unused messages, configuration item, registration, and test helpers are removed while the stated compatibility behavior is preserved.
Written by the indexing model from the issue text.
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 #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 #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. Their gRPC status remainsUNIMPLEMENTED; only the status description changes, from unimplemented-method wording to unregistered-service wording.
Impact
The change keeps the same gRPC status code and 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, for clients that use the removed definitions. Runtime behavior and the wire format do not change because all four RPCs already return
UNIMPLEMENTED. Clients such as wallet-cli or Trident may keep their own copy ofapi.protoor generated gRPC code; if that code usesWalletExtensionGrpcor the five messages listed above, it must be updated when the new proto is adopted. - 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
- Dominant language
- Java
- Stars
- 4.2k
- Forks
- 1.7k
- Avg merge
- 6d 20h
- Merged PRs (30d)
- 14
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tronprotocol/java-tron
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
tronprotocol/java-tron#6969 · 8 comments ·
-
type:feature
Difficulty 5/5 Over a week Newbie friendliness 48/100
tronprotocol/java-tron#6963 · 6 comments ·
-
type:feature
Difficulty 5/5 Over a week Newbie friendliness 28/100
tronprotocol/java-tron#6959 · 3 comments ·
-
type:feature
Difficulty 5/5 Over a week Newbie friendliness 38/100
tronprotocol/java-tron#6958 · 3 comments ·
-
topic:release type:tracking
Difficulty 4/5 3-5 days Newbie friendliness 35/100
tronprotocol/java-tron#6957 · 2 comments ·
All issues in tronprotocol/java-tron
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
bug needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
objectionary/hone-maven-plugin#1061 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
spring-projects/spring-modulith#1895 ·