fix: bump cometbft and TxReplacementDecorator into ante handler to unblock stuck mempool sequences#661
fix: bump cometbft and TxReplacementDecorator into ante handler to unblock stuck mempool sequences#661hoank101 wants to merge 15 commits into
Conversation
* - fix ibc handling in wasm (#77) - remove fork code to use upstream - remove unused code * Problem: cometbft not up to date * add v14_2 * bump version * bump version * bump version * fix legacy query staking (#79) * fix legacy query staking * bet * fix legacy params for validator delegation fallback * Bet * bet --------- Co-authored-by: Khanh Hoa <hoa@notional.ventures> Co-authored-by: Tuan Tran <tropicaldog17@gmail.com> * consistent alias --------- Co-authored-by: StrathCole <7449529+StrathCole@users.noreply.github.com> Co-authored-by: Kien Trinh <51135161+kien6034@users.noreply.github.com> Co-authored-by: Tuan Tran <tropicaldog17@gmail.com>
fix legacy staking query timeout
| for k := range info.newTxBytesSet { | ||
| newSet[k] = struct{}{} | ||
| } |
| for k := range info.newTxBytesSet { | ||
| if k != key { | ||
| newSet[k] = struct{}{} | ||
| } | ||
| } |
| for k := range info.newTxBytesSet { | ||
| newSet[k] = struct{}{} | ||
| } |
| for k := range info.newTxBytesSet { | ||
| if k != key { | ||
| newSet[k] = struct{}{} | ||
| } | ||
| } |
|
Hi @StrathCole @fragwuerdig can you guys review this PR? |
|
Wouldn't it be rather necessary to fix the root cause (a tx that doesn't make it into a block should not pass checkTx)? |
The fee.go changes address the most likely root cause (burn tax calculation inconsistency between CheckTx and RecheckTx). However, fixing it completely is not possible within Terra alone - CometBFT's CheckTx is by design a soft filter, and any chain state change (governance tax/gas-price update) between submission and inclusion creates a new discrepancy. The TxReplacementDecorator is defense-in-depth: it provides a recovery path when any future discrepancy causes the same deadlock pattern, which is especially critical for validator operations where getting stuck means being jailed indefinitely. |
Fix #648
Summary of changes
Problem
A validator operator wallet became permanently stuck and the validator was jailed with no way to unjail, because a CheckTx-accepted transaction at the committed sequence never made it into a block:
identical tx is rejected by the cache (code 19).
The result is a deadlock: every later tx from the wallet is stranded behind a sequence-432 tx that can neither be included nor replaced. For a validator this is fatal — the MsgUnjail / MsgEditValidator txs needed
to recover are themselves queued behind the stuck sequence.
Report of required housekeeping
(FOR ADMIN) Before merging