Skip to content
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

Merged
merged 49 commits into from
Jun 18, 2024

Conversation

ninabarbakadze
Copy link
Member

@ninabarbakadze ninabarbakadze commented Apr 5, 2024

Description

Fixes #1281

Opens #1381

@ninabarbakadze ninabarbakadze marked this pull request as ready for review June 6, 2024 15:55
@ninabarbakadze ninabarbakadze requested a review from a team as a code owner June 6, 2024 15:55
@ninabarbakadze ninabarbakadze requested review from ramin, evan-forbes and cmwaters and removed request for a team and ramin June 6, 2024 15:55
rootulp
rootulp previously approved these changes Jun 6, 2024
Copy link
Collaborator

@rootulp rootulp left a 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

mempool/cache.go Outdated Show resolved Hide resolved
mempool/cache.go Outdated Show resolved Hide resolved
mempool/cache.go Show resolved Hide resolved
mempool/cache.go Outdated Show resolved Hide resolved
mempool/cat/pool.go Outdated Show resolved Hide resolved
mempool/v0/clist_mempool.go Outdated Show resolved Hide resolved
mempool/v0/clist_mempool.go Outdated Show resolved Hide resolved
mempool/v1/mempool.go Outdated Show resolved Hide resolved
rpc/core/tx_status.go Outdated Show resolved Hide resolved
rpc/core/tx_status.go Outdated Show resolved Hide resolved
rpc/core/tx_status.go Outdated Show resolved Hide resolved
mempool/v1/mempool.go Outdated Show resolved Hide resolved
mempool/v1/mempool.go Outdated Show resolved Hide resolved
mempool/cat/pool.go Show resolved Hide resolved
mempool/mock/mempool.go Outdated Show resolved Hide resolved
rpc/core/tx_status.go Outdated Show resolved Hide resolved
@ninabarbakadze ninabarbakadze marked this pull request as draft June 11, 2024 08:41
@ninabarbakadze ninabarbakadze marked this pull request as ready for review June 13, 2024 15:00
@@ -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 {
Copy link
Collaborator

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 Show resolved Hide resolved
// 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit

Suggested change
// 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

Copy link
Collaborator

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?

Copy link
Member Author

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.

Copy link
Contributor

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

@@ -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.
Copy link
Collaborator

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.

Comment on lines 191 to 194
// 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
}
Copy link
Collaborator

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.

Copy link
Member Author

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

Copy link
Contributor

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

mempool/v1/mempool.go Outdated Show resolved Hide resolved
Copy link
Contributor

@cmwaters cmwaters left a 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

@@ -92,6 +94,7 @@ func NewTxPool(
proxyAppConn: proxyAppConn,
metrics: mempool.NopMetrics(),
rejectedTxCache: NewLRUTxCache(cfg.CacheSize),
evictedTxCache: NewLRUTxCache(cfg.CacheSize),
Copy link
Contributor

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

@@ -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 {
Copy link
Contributor

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

Copy link
Member Author

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?

Comment on lines 191 to 194
// 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
}
Copy link
Contributor

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

@ninabarbakadze ninabarbakadze marked this pull request as draft June 17, 2024 14:11
Copy link
Member Author

@ninabarbakadze ninabarbakadze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added txstatus in v0 @cmwaters @rootulp

@ninabarbakadze ninabarbakadze marked this pull request as ready for review June 17, 2024 17:14
rootulp
rootulp previously approved these changes Jun 17, 2024
mempool/cat/store.go Outdated Show resolved Hide resolved
}

// 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.
Copy link
Collaborator

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Contributor

@cmwaters cmwaters left a 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

Comment on lines +20 to +25
const (
txStatusUnknown string = "UNKNOWN"
txStatusPending string = "PENDING"
txStatusEvicted string = "EVICTED"
txStatusCommitted string = "COMMITTED"
)
Copy link
Contributor

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

Copy link
Member Author

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

Comment on lines +231 to +234
txInfo := env.BlockStore.LoadTxInfo(hash)
if txInfo != nil {
return &ctypes.ResultTxStatus{Height: txInfo.Height, Index: txInfo.Index, Status: txStatusCommitted}, nil
}
Copy link
Contributor

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

Copy link
Member Author

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

@ninabarbakadze ninabarbakadze merged commit ff2bff4 into celestiaorg:main Jun 18, 2024
15 checks passed
@ninabarbakadze ninabarbakadze deleted the nina/current-tx-status branch June 18, 2024 13:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide the current status of a transaction for clients
4 participants