Add txmgr rpc api #10632
Add txmgr rpc api #10632
Conversation
op-service/txmgr/txmgr.go
Outdated
| @@ -124,7 +141,8 @@ type SimpleTxManager struct { | |||
| nonce *uint64 | |||
| nonceLock sync.RWMutex | |||
|
|
|||
| pending atomic.Int64 | |||
| numPending atomic.Int64 | |||
| pendingTxs map[uint64]*PendingTxWithCancel | |||
There was a problem hiding this comment.
Does this data structure provide everything we need? Namely, does the assumption that there will only ever be one pendingTx per nonce hold true? Or would we want to nest a map or slice to allow for multiple in-flight pending txs for a single nonce, e.g.: pendingTxs map[uint64]map[common.Hash]*PendingTxWithCancel
There was a problem hiding this comment.
We resubmit at the same nonce with bumped gas, but have a single outer loop which handles that resubmit which could cancel all of the variations of the transaction. Per nonce is probably the easiest way to manually cancel a transaction
|
Semgrep found 2 Variable Semgrep found 1 Please create a GitHub ticket for this TODO. Ignore this finding from todos_require_linear. |
| @@ -249,6 +249,7 @@ func (ps *ProposerService) initRPCServer(cfg *CLIConfig) error { | |||
| if cfg.RPCConfig.EnableAdmin { | |||
| adminAPI := rpc.NewAdminAPI(ps.driver, ps.Metrics, ps.Log) | |||
| server.AddAPI(rpc.GetAdminAPI(adminAPI)) | |||
| server.AddAPI(txmgr.NewTxmgrApi(ps.TxManager, ps.Metrics, ps.Log)) | |||
There was a problem hiding this comment.
Currently the op-challenger does not have an rpc server. Should we create one (similar to how the op-proposer has an rpcServer implemented here) so that we also add the txmgr_ (and perhaps admin_) rpc methods to that service? If we add an rpc server to op-challenger, I'm assuming it would be part of this struct.
There was a problem hiding this comment.
cc @ajsutton. I think it would helpful to have one. I think when we first created the challenge it wasn't easy to quickly add the RPC service b/c of how startup was done.
There was a problem hiding this comment.
I don't recall ever looking at adding RPC to the op-challenger. Certainly happy to have it added since it seems useful and if someone can take on that work. Otherwise we should log an issue to track it but I don't think the proofs team will have capacity for it in the short term.
bitwiseguy
force-pushed
the
ss/txmgr-admin-rpc
branch
from
05dc80f
to
03cb45c
Compare
| @@ -196,6 +217,12 @@ type TxCandidate struct { | |||
| Value *big.Int | |||
| } | |||
|
|
|||
| type PendingTxWithCancel struct { | |||
| tx *types.Transaction | |||
There was a problem hiding this comment.
It might be nice to extend this to an array because the key for this is a nonce & it will often have multiple transactions (different gas prices + sig, same data) per nonce when resubmitting.
| return receipt, err | ||
| } | ||
|
|
||
| type PendingTxRPC struct { |
There was a problem hiding this comment.
Do we want to include blobs here?
|
This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
|
Can we close this, since it is being replaced by #10897 ? |
Yes. Closing this PR now |
Description
Chain operators have hit issues in the past where txs get stuck in their nodes. This PR adds a new
txmgr_json rpc interface for nodes that use theTxManager(i.e.op-batcher,op-challenger,op-proposer) to give them more flexibility/insight when troubleshooting tx submission issues.Tests
Added unit tests to the
op-service/txmgrpackage. Updatedop-e2etests to ensure their use of mockedTxManageradheres to the new interface with its additional methods.Additional context
Config rpc methods:
txmgr_getMinBaseFeetxmgr_setMinBaseFeetxmgr_getPriorityFeetxmgr_setPriorityFeetxmgr_getMinBlobFeetxmgr_setMinBlobFeetxmgr_getFeeThresholdtxmgr_setFeeThresholdtxmgr_getBumpFeeRetryTimetxmgr_setBumpFeeRetryTimePending tx rpc method:
txmgr_getPendingTxstxmgr_cancelPendingTxMetadata