feat: Transaction manager for centralised txn submission#3385
Conversation
This permits multiple bots to share a single EOA with centralised transaction lifecycle management, nonce tracking etc. This is experimental but should permit more app-level features to be added for a given EOA without leading to increased congestion on the chain.
pxrl
requested review from
bmzig,
dijanin-brat,
mrice32 and
nicholaspai
as code owners
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 821f0e45cf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let response: TransactionResponse; | ||
| try { | ||
| response = await backend.submit(txn); | ||
| } catch (error) { |
There was a problem hiding this comment.
The redis branch bypasses _submit, so transactions with ensureConfirmation: true now return immediately after ACK instead of waiting for on-chain confirmation. This is a behavior regression versus the RPC path and can break sequencing flows that rely on confirmation before continuing (e.g. approval-then-action patterns), because callers that previously depended on submit() blocking for these transactions will now race ahead.
Useful? React with 👍 / 👎.
| const [r] = await this.txnClient.submit(req.chainId, [augTxn]); | ||
| response = r; |
There was a problem hiding this comment.
TransactionClient.submit() can resolve with an empty array on submission failure (it logs and returns partial results), but this code destructures [r] and returns undefined without publishing an ACK failure. In that case processRequest exits as if a failure ACK was already emitted, and the caller-side backend waits indefinitely on ackD.promise for this request id.
Useful? React with 👍 / 👎.
| this.subscribingPromises.set(key, pending); | ||
| } | ||
| await pending; |
There was a problem hiding this comment.
The first subscription attempt for a (chainId,eoa) key is cached in subscribingPromises, but the entry is never removed. If sub() fails once (for example during a transient Redis disconnect), the cached rejected promise is reused forever, so all later submits for that key fail immediately even after Redis recovers.
Useful? React with 👍 / 👎.
1 participant
This permits multiple bots to share a single EOA with centralised transaction lifecycle management, nonce tracking etc. This is experimental but should permit more app-level features to be added for a given EOA without leading to increased congestion on the chain.