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