txmgr: admin rpc

[sebastianst]

We should add an admin rpc to the txmgr to help debugging and fixing tx submission issues. Some ideas

• getPendingTxs() - would return txHash, nonce, status, timestamp, size (data or blob), type, sender, to, data/blob (only optionally by parameter), full encoded tx (optional, ready to be used by cast publish), gas fields, and the auxiliary attributes (tbd, like channel id), ...
• cancelSend(nonce) - immediately drop all pending txs for the given nonce. TBD what happens to all higher nonces?
• getters and setters for gas configs and other params
  • threshold
  • min base fee, prio fee, blob fee
  • retry & bump times
  • any other parameters?

[bitwiseguy]

@sebastianst a few questions:

1. should we implement a way to call the geth json rpc method txpool_content to retrieve pending txs or are you thinking that we should track pending txs in-memory (i.e. we could add a pendingTxs map nonce --> tx to the SimpleTxManager struct)?
2. Are you expecting the methods you mentioned (e.g. getPendingTxs() and cancelSend(nonce)) to be accessible, after abstraction layers, through (a) cli commands, (b) json rpc requests, or (c) a different way?
   • Edit: Seems like we probably want to add admin_* methods to the json rpc server on the op-proposer, op-challenger. Those two services already have admin api namespaces. Should we also add an admin api to the op-node and add the same methods? It doesn't look like the op-node currently has a TxMgr 🤔

[sebastianst]

@bitwiseguy

1. this is only about locally pending txs in the txmgr, not what's in the remote L1's tx pool
2. This is about adding json-rpcs in the admin_* namespace. This should be done in a reusable way in the txmgr package so that other services that use it can add it to their admin ns. The op-node doesn't send txs, so it doesn't have a txmgr. Only the batcher, proposer, and challenger have a txmgr.

[BlocksOnAChain]

we will try to close this one out in Cycle 10.