The startup parameter --save-internaltx does not take effect

[lily309]

Software Versions

OS : Mac OS X
JVM : Amazon.com Inc. 1.8.0_362 x86_64
Git : e811deff938578d8f85f497f9be2c4045d4da8c6
Version : 4.7.7
Code : 18386

Expected behaviour

When I turn on the switch for internal transaction logging by adding the --save-internaltx parameter to the startup parameters, the internal transactions that occur in the transaction are never available through the fullnode http interface.

Here is the test contract I deployed

// SPDX-License-Identifier: MIT

pragma solidity >=0.8.0;

contract A {
    function a() external payable {
        payable(msg.sender).transfer(msg.value);
    }
}

Here are the results of the transaction_info I queried

curl http://127.0.0.1:8090/wallet/gettransactioninfobyid?value=34ba7609907e3432df4d54da787d22f6556ab390a2b454da52380f1e3dbda065

{
"id": "34ba7609907e3432df4d54da787d22f6556ab390a2b454da52380f1e3dbda065",
"fee": 693200,
"blockNumber": 52,
"blockTimeStamp": 1740553053000,
"contractResult": [
""
],
"contract_address": "41b665df62df91aceb92712d4f06443cccbfb88050",
"receipt": {
"energy_fee": 693200,
"energy_usage_total": 6932,
"net_usage": 284,
"result": "SUCCESS"
}
}

Actual behaviour

I should be able to query an internal transaction.

Frequency

Always

Steps to reproduce the behaviour

1. Start a private chain with the command java -jar FullNode.jar -c config.conf --witness --save-internaltx
2. Deploy a test contract as described above.
3. Call the a method of the deployed contract.
4. Query the transaction execution results through the /wallet/gettransactioninfobyid interface.

Backtrace

None

[yanghang8612]

Can you please provide a snippet of the vm namespace in the config file.
Roughly as shown below:

vm = {
  ...
}

[lily309]

@yanghang8612

vm = {
  # supportConstant = false
  # maxEnergyLimitForConstant = 100000000
  # minTimeRatio = 0.0
  # maxTimeRatio = 5.0
  # saveInternalTx = false

Is there something wrong with my configuration here? I just commented out that part of the configuration all together.

[yanghang8612]

@yanghang8612

vm = {
  # supportConstant = false
  # maxEnergyLimitForConstant = 100000000
  # minTimeRatio = 0.0
  # maxTimeRatio = 5.0
  # saveInternalTx = false

Is there something wrong with my configuration here? I just commented out that part of the configuration all together.

OK, got it. It seems that the --save-internaltx parameter in commandline is not taking effect and the following code is causing the problem.

Args.java

    PARAMETER.saveInternalTx =
        config.hasPath(Constant.VM_SAVE_INTERNAL_TX)
            && config.getBoolean(Constant.VM_SAVE_INTERNAL_TX);

In the above code, PARAMETER.saveInternalTx will be overridden to false if vm.saveInternalTx is not configured in the config file.This causes --save-internaltx in the startup parameter to fail. In other words, PARAMETER.saveInternalTx will always be overridden to the configured state in the configuration file.

[abn2357]

@yanghang8612

vm = {
  # supportConstant = false
  # maxEnergyLimitForConstant = 100000000
  # minTimeRatio = 0.0
  # maxTimeRatio = 5.0
  # saveInternalTx = false

Is there something wrong with my configuration here? I just commented out that part of the configuration all together.

OK, got it. It seems that the --save-internaltx parameter in commandline is not taking effect and the following code is causing the problem.

Args.java

    PARAMETER.saveInternalTx =
        config.hasPath(Constant.VM_SAVE_INTERNAL_TX)
            && config.getBoolean(Constant.VM_SAVE_INTERNAL_TX);

In the above code, PARAMETER.saveInternalTx will be overridden to false if vm.saveInternalTx is not configured in the config file.This causes --save-internaltx in the startup parameter to fail. In other words, PARAMETER.saveInternalTx will always be overridden to the configured state in the configuration file.

@yanghang8612 Is it reasonable? Traditionally, which has higher priority, configuration file or command line?

[yanghang8612]

@abn2357 I think command line parameters passed in by the user should have a higher priority than configuration files. What do you think?

[Sunny6889]

what if there is a conflict between configuration and command line parameters?

[abn2357]

@abn2357 I think command line parameters passed in by the user should have a higher priority than configuration files. What do you think?

@yanghang8612 I share the same viewpoint as you, hence the aforementioned question.

[yanghang8612]

@Sunny6889 Based on the existing code, the actual settings of the parameters will be as in the configuration file.