-
Notifications
You must be signed in to change notification settings - Fork 142
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
common,cli,agent: remove multi-network-mode #1090
base: main
Are you sure you want to change the base?
Conversation
b236134
to
29c901e
Compare
1070468
to
531a773
Compare
531a773
to
5e72ec7
Compare
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.
So many red lines, I love it... leaving a few comments for now, but still reviewing
logger.warn(`Failed to fetch max allocation epochs`, { error }), | ||
}, | ||
) | ||
const { network } = this.networkAndOperator |
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: could const { network, operator } = this.networkAndOperator
be done once at the beginning of the function? then you don't need to get the network/operator again in each of these eventuals
const { network } = this.networkAndOperator | ||
if ( | ||
this.deploymentManagement === DeploymentManagementMode.AUTO || | ||
network.networkMonitor.poiDisputeMonitoringEnabled() |
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.
OOoh was this broken?
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 so this was an optimization I made for the upgrade indexer which was querying all (some 25k) deployments from the graph node in this eventual, despite not needing to. This was causing some 30 mins (!) being spent on that request in some cases, blocking all other work.
Neither DeploymentManagementMode.AUTO
or PoiDisputeMonitoring were enabled there so it made sense to block the call behind that. IIRC In a later testing session I found that when DeploymentManagementMode.AUTO
was enabled, this still wasn't being hit due to the eventual in multiNetwork and networkMapped not having a value at the right time. So this is re-enabling the optimization to the narrower case, but now without the networkMapped hoop to jump through.
logger.warn( | ||
`Failed to merge L2 transfer decisions, trying again later`, | ||
{ | ||
const networkDeploymentAllocationDecisions: Eventual<AllocationDecision[]> = |
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.
Love all the deleted code here. One thing that comes to mind, however: is it possible that the Upgrade Indexer is currently allocating to some subgraphs based on the L2 transfer conditions? Not sure how we could validate that, but it would be good to make sure this won't make us drop any subgraphs
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.
(Maybe this can be inferred from Upgrade Indexer logs?)
}, | ||
) | ||
const { network } = this.networkAndOperator | ||
const allocationsByNetwork = |
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: allocationsByNetwork is probably not the best name for this now
} | ||
return allocationDecisions | ||
const { network, operator } = this.networkAndOperator | ||
let validatedAllocationDecisions = allocationDecisions |
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.
Should we clone to avoid mutation here?
decision.deployment.bytes32 == networkSubgraphDeployment.id.bytes32, | ||
) | ||
if (networkSubgraphIndex >= 0) { | ||
allocationDecisions[networkSubgraphIndex].toAllocate = 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.
this is mutating allocationDecisions instead of validatedAllocationDecisions - it works because they're the same array by reference, but this looks risky
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.
Finished reviewing, just a couple more details
operator: network.transactionManager.wallet.address, | ||
const networkLogger = logger.child({ | ||
protocolNetwork: this.network.specification.networkIdentifier, | ||
indexer: this.network.specification.indexerOptions.address, |
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.
might it still be useful to log the operator address here?
|
||
return queryAllocations(logger, networkSubgraph, variables, context) | ||
}, | ||
const allocationsByNetwork = await queryAllocations( |
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: same as above, allocationsByNetwork
might be a confusing name? maybe just allocationsResult
?
This PR removes multi-network mode while preserving the network config parsing logic that it was tied to. This enables a significant reduction in complexity.
Changes:
network-specifications-dir
network-specifications-dir
is provided then the values are used, otherwise single-network mode's style of pulling values from argv/env are used.