New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor_: add more default node config values for frontend when doing local pair sync #5098
refactor_: add more default node config values for frontend when doing local pair sync #5098
Conversation
Jenkins BuildsClick to see older builds (8)
|
if request.LogLevel != nil { | ||
nodeConfig.LogLevel = *request.LogLevel | ||
nodeConfig.LogEnabled = true | ||
|
||
} else { | ||
nodeConfig.LogEnabled = false | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please elaborate why remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's duplicated... you can see them already in line 233
server/pairing/sync_device_test.go
Outdated
} | ||
|
||
// need specify cluster config here, otherwise TestPairingThreeDevices will fail due to no messages(CR) received | ||
// TODO(frank) need to figure out why above happen | ||
clusterConfig, err := params.LoadClusterConfigFromFleet("eth.prod") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's replace eth.prod
with constant?
Line 6 in 34c693b
FleetProd = "eth.prod" |
Or even better take one of supported fleets:
Lines 24 to 29 in 34c693b
// DefaultWakuNodes is a list of "supported" fleets. This list is populated to clients UI settings. | |
var supportedFleets = map[string][]string{ | |
FleetWakuV2Prod: {"enrtree://ANEDLO25QVUGJOUTQFRYKWX6P4Z4GKVESBMHML7DZ6YK4LGS5FC5O@prod.wakuv2.nodes.status.im"}, | |
FleetWakuV2Test: {"enrtree://AO47IDOLBKH72HIZZOXQP6NMRESAN7CHYWIBNXDXWRJRZWLODKII6@test.wakuv2.nodes.status.im"}, | |
FleetShardsTest: {"enrtree://AMOJVZX4V6EXP7NTJPMAYJYST2QP6AJXYW76IU6VGJS7UVSNDYZG4@boot.test.shards.nodes.status.im"}, | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take the first since i only trust eth.prod ATM. 🙂
// following specifiedXXX variables are used to check if frontend has specified the value | ||
// if not, the default value is set. NOTE: we also check 2 extra fields: WakuV2Config(LightClient|Nameserver) | ||
// see api.SetFleet for more details | ||
specifiedVerifyTransactionURL := c.ShhextConfig.VerifyTransactionURL | ||
specifiedVerifyENSURL := c.ShhextConfig.VerifyENSURL | ||
specifiedVerifyENSContractAddress := c.ShhextConfig.VerifyENSContractAddress | ||
specifiedVerifyTransactionChainID := c.ShhextConfig.VerifyTransactionChainID | ||
specifiedNetworkID := c.NetworkID | ||
specifiedNetworks := c.Networks | ||
specifiedUpstreamConfigURL := c.UpstreamConfig.URL | ||
specifiedLogEnabled := c.LogEnabled | ||
specifiedLogLevel := c.LogLevel | ||
specifiedFleet := c.ClusterConfig.Fleet | ||
specifiedInstallationID := c.ShhextConfig.InstallationID | ||
specifiedTorrentConfigEnabled := c.TorrentConfig.Enabled | ||
specifiedTorrentConfigPort := c.TorrentConfig.Port | ||
|
||
if len(specifiedNetworks) == 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm missing something, but this looks very confusing to me.
I know you have plans on re-implementing this with smth like login-with-syncing
request concept. I think we need to go with without merging this PR. What's the point?
We really should not pass nodeConfig
from client side, this is wrong. And will very soon become a pain, as we want to remove nodeConfig
handling from desktop.
-
In general there's no need on passing
NodeConfig
from client.
In desktop we send a very default struct, no custom fields. -
If we look at
ReceiverConfig
, we can see a few customizations there already, e.g.SettingCurrentNetwork
:
status-go/server/pairing/config.go
Lines 25 to 42 in 3bacb84
type ReceiverConfig struct { // nodeConfig is required, but we'll validate it separately NodeConfig *params.NodeConfig `json:"nodeConfig"` // ReceiverConfig.KeystorePath must not end with keyUID (because keyUID is not known yet) KeystorePath string `json:"keystorePath" validate:"required,not_end_keyuid"` // DeviceType SendPairInstallation need this information DeviceType string `json:"deviceType" validate:"required"` KDFIterations int `json:"kdfIterations" validate:"gte=0"` // SettingCurrentNetwork corresponding to field current_network from table settings, so that we can override current network from sender SettingCurrentNetwork string `json:"settingCurrentNetwork" validate:"required"` DeviceName string `json:"deviceName"` DB *multiaccounts.Database `json:"-"` LoggedInKeyUID string `json:"-"` }
Let's just follow this path and add required fields to this structure.
For sake of simplicity/readability/maintainability let's compose it into a single struct, maybe NodeConfigOptions
(or other better name):
type NodeConfigOptions struct { // find better naming
VerifyTransactionURL string
...
}
@qfrank let me know what you think
We could merge this solution and improve it in a separate PR, but I don't understand why not do it properly straightaway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point is: This PR has sorted out which parameters should be configurable for the frontend, and which parameters can have default values provided by the backend. The frontend no longer needs to know so many configuration details of nodeconfig(there is a mobile PR to decrease such details). Refactoring is a step-by-step process.
We really should not pass nodeConfig from client side, this is wrong
agreed
Let's just follow this path and add required fields to this structure.
agreed
Let's merge this and improve it in a separate PR ❤️ @igor-sirotin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this PR @qfrank . 🙏
For handling NodeConfig in local syncing, we only need a small amount of parameters if any at all.
Unless the parameter is related to getting keys or db data, shouldn't config data be the responsibility of the recipient / bootstrapped device? I may be mistaken about something, but I don't think we should share the nodeconfig settings of the sending / bootstrapping device.
Please forgive me if I'm missing something.
yeah I agree, but currently there still are some params(e.g. OpenseaAPIKey) relate to node config need client to pass, we will remove NodeConfig and put the bare minimum needed from the client in some places as @igor-sirotin suggested before finally @Samyoul |
c4f8840
to
0d394fb
Compare
…g local pair sync
0d394fb
to
2af2935
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @qfrank.
this is a continue work to PR
relate comment
status: ready.