At the moment the node configuration code is very confusing, and it contains an unused (requires checking) functionality for saving parameters to the database.
For example let's review statusd's startup code:
1) statusd starts with a config file, which structured identical to NodeConfig (No, it is NodeConfig!)
2) Heresome options are copied to APIConfig to pass it to backend.RestoreAccountAndLogin
3) Next the generateOrImportAccount loads a default config and overrides it with options in APIConfig. (requests.RestoreAccount derived from requests.CreateAccount, that's why it has APIConfig)
Basically, all options missing in the APIConfig, will be ignored.
Problem
Based on this discussion
At the moment the node configuration code is very confusing, and it contains an unused (requires checking) functionality for saving parameters to the database. For example let's review
statusd's startup code:1)
statusdstarts with a config file, which structured identical to NodeConfig (No, it is NodeConfig!) 2) Here some options are copied toAPIConfigto pass it tobackend.RestoreAccountAndLogin3) Next thegenerateOrImportAccountloads a default config and overrides it with options inAPIConfig. (requests.RestoreAccountderived fromrequests.CreateAccount, that's why it hasAPIConfig)Basically, all options missing in the
APIConfig, will be ignored.Implementation
The proposal of this fix it to get rid of saving the
NodeConfigto the database, that was mentioned by Igor here: https://github.com/status-im/status-go/pull/5346#discussion_r1652476903