Replace TransactionFiltererAPI mutex with a channel#4428
Replace TransactionFiltererAPI mutex with a channel#4428MishkaRogachev wants to merge 3 commits intomasterfrom
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #4428 +/- ##
==========================================
- Coverage 33.03% 32.32% -0.71%
==========================================
Files 493 493
Lines 58290 58315 +25
==========================================
- Hits 19256 18853 -403
- Misses 35675 36109 +434
+ Partials 3359 3353 -6 |
2c947df to
9869061
Compare
❌ 8 Tests Failed:
View the top 3 failed tests by shortest run time
📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
Tristan-Wilson
left a comment
There was a problem hiding this comment.
I think the old code with the mutex was clearer and easier to reason about.
cmd/transaction-filterer/api/api.go
Outdated
| t.apiMutex.Lock() | ||
| defer t.apiMutex.Unlock() | ||
| t.arbFilteredTransactionsManager = arbFilteredTransactionsManager | ||
| t.queue <- func() { |
There was a problem hiding this comment.
Should also select for ctx.Done
cmd/transaction-filterer/api/api.go
Outdated
| case t.queue <- func() { | ||
| if t.arbFilteredTransactionsManager == nil { | ||
| reply <- errors.New("sequencer client not set yet") | ||
| return | ||
| } | ||
| txOpts := *t.txOpts | ||
| txOpts.Context = ctx | ||
| log.Info("Received call to filter transaction", "txHashToFilter", txHashToFilter.Hex()) | ||
| tx, err := t.arbFilteredTransactionsManager.AddFilteredTransaction(&txOpts, txHashToFilter) | ||
| if err != nil { | ||
| log.Warn("Failed to filter transaction", "txHashToFilter", txHashToFilter.Hex(), "err", err) | ||
| reply <- err | ||
| return | ||
| } | ||
| log.Info("Submitted filter transaction", "txHashToFilter", txHashToFilter.Hex(), "txHash", tx.Hash().Hex()) | ||
| return tx.Hash(), nil | ||
| txHash = tx.Hash() | ||
| reply <- nil | ||
| }: | ||
| case <-ctx.Done(): |
There was a problem hiding this comment.
I think there is a situation where this is called and the closure is enqueued, and then later its context is canceled, and we return an error to the caller at line 84, but the closure is still enqueued and then will execute later, which will fail immediately inside the contract binding call and probably fail immediately due to the canceled context and log an error. At least it won't hang forever since the reply chan has size 1. I think the decoupling introduced by the channel isn't worth it here.
There was a problem hiding this comment.
I made another attempt with the channel, and now it should be a bit clearer
diegoximenes
left a comment
There was a problem hiding this comment.
One issue with the mutex approach is that, if the incoming call is aborted, the apiMutex.Lock call will not be canceled.
Current strategy solves that.
However this is not a big issue given the current architecture, e.g., a single sequencer replica calling this API sequentially.
This kind of change can make it easier to, in the future, adding retry logic when calling the sequencer, etc.
But the extra complexities introduced here are not worth it.
You can simplify mutex usage by making TransactionFiltererAPI.Filter not return a transaction hash, we don't use this response today.
Fixes NIT-4499
Address #4294 (comment)