This repository was archived by the owner on May 28, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 37
[watcher] performance concerns & final wrap up #1412
Copy link
Copy link
Open
Labels
ChoreDevops or refactoring taskDevops or refactoring taskp3: Features/refactorsLarger enhancements driven by user needs + Refactors to improve bad patterns.Larger enhancements driven by user needs + Refactors to improve bad patterns.
Description
Before we turn the watcher on in prod, 2 potential performance issues should be addresses
- Currently watcher stores all
StateProgressedandChallengeUpdatedevents emitted from the watched ChallengeRegistries. We really ought to filter those out so that we only store the events that are relevant to our publicIdentifier's channels' apps. - We should save the block number as lastProcessedBlock in the store at the point where we run the setup protocol & wait to start the watcher until setup finishes. We're currently starting to download event logs from the block where our challenger registry got deployed so, that's a lot of blocks to scan.
Once these ^ are done & watcher tests in modules/node/src/test/e2e/challenge.spec.ts are passing, we can re-activate the watchers by passing in the chain providers instead of an empty object in:
modules/client/src/connect.tsmodules/node/src/challenge/challenge.service.ts
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
ChoreDevops or refactoring taskDevops or refactoring taskp3: Features/refactorsLarger enhancements driven by user needs + Refactors to improve bad patterns.Larger enhancements driven by user needs + Refactors to improve bad patterns.