improve(relayer): Drop slow fill request queries #1340
Conversation
Making room for follow-up changes to improve relayer performance.
Rather than duplicating the array of unfilled deposits, just check it as the first conditional in the subsequent loop. This allows the entire function to be subsequently factored away, which will occur in a follow-up commit.
Factoring out this functionality permits it to be executed in parallel per destination chain.
…layerRefactorEvaluate
…layerRefactorEvaluate
The relayer currently implements late-stage checking of the fill status on a per-deposit basis. This is fairly slow and inefficient, but does successfully protect against an avalanche of failed fill simulations that result from overlapping bot runs. This change implements batched querying of all deposits for each destination chain. This is significantly more efficient in terms of RPC consumption, and should allow for subsequent "already filled" filtering to occur much faster. It's also a key enabler for some subsequent efficiency improvements.
By retaining the deposit FillStatus on the destination chain it's possible to skip scraping for RequestedV3SpeedUp events. This reduces the RPC load during SpokePoolClient update.
pxrl
requested review from
mrice32,
nicholaspai and
james-a-morris
as code owners
Agree - that's not changed here and it remains as-is 👍 Slow relays is still 100% opt-in. |
That's important for the proposer/disputer, but is relevant for the relayer? This PR only affects the relayer's SpokePoolClient update, and deposit update requests don't affect relayer repayments so I can't see any obvious problem with ignoring them. |
Yeah - I also wasn't able to reason my way to any problem with dropping these events. I'll merge this on Monday 👍 |
By retaining the deposit FillStatus on the destination chain it's possible to skip scraping for RequestedV3SpeedUp events. This reduces the RPC load during SpokePoolClient update.