-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
refactor incoming tx controller #10639
Conversation
Builds ready [adb61ce]
Page Load Metrics (593 ± 59 ms)
|
adb61ce
to
534a292
Compare
Builds ready [534a292]
Page Load Metrics (644 ± 33 ms)
|
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 looks great!
Although I've changed it from network to chainId, this shouldn't result in functional changes except where user's are using custom networks with chainIds that match default chains.
I think even for those users it won't be a functional change, as we were using the chainId
and mapping it back to a type (using CHAIN_ID_TO_NETWORK_ID_MAP
). So it was effectively grouping by chainId
already, even though it was keyed by the network identifier. Unless I missed something.
No, that's correct. This should be an entirely non-functional change. |
Builds ready [9b87f73]
Page Load Metrics (580 ± 45 ms)
|
Builds ready [fd4f5ee]
Page Load Metrics (593 ± 35 ms)
|
fd4f5ee
to
dfba6c0
Compare
Builds ready [dfba6c0]
Page Load Metrics (594 ± 45 ms)
|
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!
Builds ready [ae29cd0]
Page Load Metrics (643 ± 35 ms)
|
ae29cd0
to
a24b030
Compare
Builds ready [a24b030]
Page Load Metrics (608 ± 29 ms)
|
a24b030
to
fe5944e
Compare
Builds ready [fe5944e]
Page Load Metrics (689 ± 56 ms)
|
@Gudahtt could use another look at this, only thing that has changed is the migration number (and test relocation due to my other 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.
LGTM!
Rationale
As a means of more deeply understanding what the incoming transaction controller does I set out to document its methods with types and descriptions. In so doing I found a number of cases where I felt like the readability of the controller could be improved. This should be a non-functional refactor. Please take care in reading the changes to the test file to see if I have altered the desired outcomes in any functional way.
This will require a migration as I renamedincomingTxLastFetchedBlocksByNetwork
toincomingTxLastFetchedBlockByChainId
. Although the value is an object storing values that are blocks, eachchainId
only has one block. Although I've changed it fromnetwork
tochainId
, this shouldn't result in functional changes except where user's are using custom networks withchainIds
that match default chains.Migration now included, and the case above doesn't exist because we were mapping chainId to provider type before, so custom network with chainId
0x1
would have had its last fetched block stored in themainnet
key