-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add tx status in mempool #1287
feat: add tx status in mempool #1287
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Suggestions were mostly optional comment improvements
Co-authored-by: Rootul P <[email protected]>
Co-authored-by: Rootul P <[email protected]>
mempool/cat/store.go
Outdated
@@ -142,14 +142,17 @@ func (s *store) getTxsBelowPriority(priority int64) ([]*wrappedTx, int64) { | |||
|
|||
// purgeExpiredTxs removes all transactions that are older than the given height | |||
// and time. Returns the amount of transactions that were removed | |||
func (s *store) purgeExpiredTxs(expirationHeight int64, expirationAge time.Time) int { | |||
func (s *store) purgeExpiredTxs(expirationHeight int64, expirationAge time.Time, evictedTxCache *LRUTxCache) int { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[no change needed] it seems like purge
could be renamed to evict
here. IMO it's easier to understand what's happening if we use consistent names for consistent things.
In other words, it isn't immediately obvious to me that purging a transaction should add it to the evicted tx cache. However, evicting a transaction seems like it should add the tx to the evicted tx cache.
mempool/mempool.go
Outdated
// Used in the RPC endpoint: TxStatus. | ||
GetTxByKey(key types.TxKey) (types.Tx, bool) | ||
|
||
// IsTxEvicted returns true if the tx is evicted from the mempool and exists in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit
// IsTxEvicted returns true if the tx is evicted from the mempool and exists in the | |
// IsTxEvicted returns true if the tx was evicted from the mempool and exists in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] what happens if the tx gets evicted from the mempool and then the user re-submits the exact same tx so that it exists in the tx cache? Is it possible for one tx to exist in both the tx cache and the evicted tx cache at the same time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it's possible that a previously evicted tx exists in both caches. evicted tx only gets rid of its records once it reaches its max size(v0) or once it's reset alongside all other caches(v1). I think how we can avoid confusion between re-added txs is if we check for eviction last.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a more correct phrasing of the method is WasRecentlyEvicted
mempool/v0/clist_mempool.go
Outdated
@@ -183,6 +183,16 @@ func (mem *CListMempool) TxsFront() *clist.CElement { | |||
return mem.txs.Front() | |||
} | |||
|
|||
// GetTxByKey is not supported by the v0 mempool but it is required to satisfy the mempool interface. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[blocking] I don't think we have rough consensus on deprecating the v0 mempool. See #1382.
IMO if it's easy to add, then we should add support for GetTxByKey
until we make a decision on deprecating the v0 mempool. If it's difficult to add support for GetTxByKey
to the v0 mempool, that should be information that we use when making the decision to deprecate or not. If that's the case, making the decision should block merging this PR.
mempool/v0/clist_mempool.go
Outdated
// IsTxEvicted is not supported by the v0 mempool but it is required to satisfy the mempool interface. | ||
func (mem *CListMempool) IsTxEvicted(key types.TxKey) bool { | ||
return false | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[blocking] I don't think we have rough consensus on deprecating the v0 mempool. See #1382.
IMO if it's easy to add, then we should add support for IsTxEvicted
until we make a decision on deprecating the v0 mempool. If it's difficult to add support for IsTxEvicted
to the v0 mempool, that should be information that we use when making the decision to deprecate or not. If that's the case, making the decision should block merging this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if i'm understanding it correctly v0 is currently not in use. I'm not sure why we'd want to support TxStatus in v0 if it's not enabled and won't be used. We could merge this pr as long as we satisfy the interface.
I have no problem implementing those methods in v0 I just don't really understand why we should
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point I think rootul is making is even although it's not the default, it is feasible that someone use the mempool v0, thus we do support it and until we stop supporting it, features like TxStatus
will need to be implemented across all implementations
Co-authored-by: Rootul P <[email protected]>
Co-authored-by: Rootul P <[email protected]>
Co-authored-by: Rootul P <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is almost done, just a few remaining remarks
mempool/cat/pool.go
Outdated
@@ -92,6 +94,7 @@ func NewTxPool( | |||
proxyAppConn: proxyAppConn, | |||
metrics: mempool.NopMetrics(), | |||
rejectedTxCache: NewLRUTxCache(cfg.CacheSize), | |||
evictedTxCache: NewLRUTxCache(cfg.CacheSize), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we perhaps make this 1/5 the size of the rejectedTxCache. The default in the config is currently 10k, so I think keeping the last 2k of evicted transactions is sufficient
mempool/cat/store.go
Outdated
@@ -142,14 +142,17 @@ func (s *store) getTxsBelowPriority(priority int64) ([]*wrappedTx, int64) { | |||
|
|||
// purgeExpiredTxs removes all transactions that are older than the given height | |||
// and time. Returns the amount of transactions that were removed | |||
func (s *store) purgeExpiredTxs(expirationHeight int64, expirationAge time.Time) int { | |||
func (s *store) purgeExpiredTxs(expirationHeight int64, expirationAge time.Time, evictedTxCache *LRUTxCache) int { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the cache been passed into the store. It feels leaky. Either the caches are built into the store or this method returns an array of evicted tx keys that the mempool can then plug into the cache. I think I would prefer the latter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I returns purged txs from the store but i'm afraid that's also api breaking?
mempool/v0/clist_mempool.go
Outdated
// IsTxEvicted is not supported by the v0 mempool but it is required to satisfy the mempool interface. | ||
func (mem *CListMempool) IsTxEvicted(key types.TxKey) bool { | ||
return false | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point I think rootul is making is even although it's not the default, it is feasible that someone use the mempool v0, thus we do support it and until we stop supporting it, features like TxStatus
will need to be implemented across all implementations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} | ||
|
||
// IsTxEvicted is not supported by the v0 mempool but it is required to satisfy the mempool interface. | ||
func (mem *CListMempool) IsTxEvicted(key types.TxKey) bool { | ||
// WasRecentlyEvicted returns false consistently as this implementation does not support transaction eviction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] why does this implementation not support transaction eviction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
evicted txs are valid transactions that were evicted because of size/ttl reasons for example when mempool is full. afaik Clist mempool on the other hand directly rejects transactions if the cache is full rather than evicting them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also no TTL on the v0 mempool
Co-authored-by: Rootul P <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - I have one minor comment which you can choose to do as a follow up PR if you wish
const ( | ||
txStatusUnknown string = "UNKNOWN" | ||
txStatusPending string = "PENDING" | ||
txStatusEvicted string = "EVICTED" | ||
txStatusCommitted string = "COMMITTED" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these private, shouldn't they be public.
For example the TxClient
is going to have some logic like: wait until tx status == committed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that we shall export it once we need it exported
txInfo := env.BlockStore.LoadTxInfo(hash) | ||
if txInfo != nil { | ||
return &ctypes.ResultTxStatus{Height: txInfo.Height, Index: txInfo.Index, Status: txStatusCommitted}, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: Does TxInfo
save the resulting code of the transaction as well? If not we should add that as a follow up issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no it doesn't I think there should be an issue for this otherwise i'll create one
Description
Fixes #1281
Opens #1381