This document consists of random notes about status-go refactoring so that we don't forget about them. Here they are:
jail.baseJSCode always end with ; somehow. Those ugly hacks adding ; to the end are annoying.0x address in case of a missing value in RPCCall.ParseFromAddress.config.UpstreamConfig.Enabled. Generally, all logic regarding RPC requests handling must be incapsulated in small components which complies to a single interface, this shouldn't be handled with if statements for different cases.preProcessRequest and postProcessRequest should be named appropriately and shouldn't be just hanging functions.StopRPCCallError which callees return but callers should instead detect an error and terminate if it's fatal or something.StatusAPI's TxQueueManager and SendTransaction are only exposed for tests and look like either a design shortcoming or test helpers. Either way, this should be fixed after tests for C bindings are made separate from testing application logic.TxQueueManager should not know about AccountManager and NodeManager. However, it should be able to send a transaction (after receiving CompleteTransaction() call). https://github.com/status-im/status-go/issues/338TxQueue and TxQueueManager handlers as after moving it to status-go, their purpose is unknown. https://github.com/status-im/status-go/issues/338common.QueuedTxID. https://github.com/status-im/status-go/issues/338NodeConfig.LogLevel seems redundant.node.RPCClient.NetworkId from NodeConfig together with UpstreamConfig as they are tightly coupled and this would decrease chances that they're inconsistent to one another.NodeManager's all start and stop methods. Start/Stop logic is overcomplicated with synchronisation and has bad naming.RunningNode field in NodeManager which will eliminate a lot of unneeded checks.geth/jail/jail_cell.go to geth/jail/cell.go