Conversation
This should be used as a workaround for: paritytech/polkadot-sdk#1202
|
|
||
| fn remove_invalid(&self, _: &[TxHash<Self>]) -> Vec<Arc<Self::InPoolTransaction>> { | ||
| // Don't do anything on purpose. | ||
| Vec::new() |
There was a problem hiding this comment.
Thank you for this! We tested something like this by forking the txpool crates here: #2186
It didn't work even with all collators running the code. (Was going to report back on the issue today).
Why? Here's my guess:
- Transaction C dependent on B dependent on A
- Txs A, B, C sent to the pool
- Tx A gets into a fork
- Txs B and C now stay in the pool (good!)
- Fork with Tx A goes away
- Tx A never gets re-added to the pool
- Txs B and C continue to be stuck
Might not be 100% correct in what is happening, but that's what it looked like from the tx pools.
We ended up using a slightly modified build of the omni-node with the fatxpool and that... might be working. Still verifying 100%.
There was a problem hiding this comment.
6. Tx A never gets re-added to the pool
If the fork is not the best chain, it will get re-added to the pool. This is also the case with the old pool.
There was a problem hiding this comment.
That did not appear to be true in tests, but perhaps something else was causing that issue.
|
Using the omni-node is working for now. Thanks for this |
2 participants
This should be used as a workaround for: paritytech/polkadot-sdk#1202
Goal
The goal of this PR is
Closes
Discussion
Checklist