All kinds of tricky considerations arose as the re-implementation moved along.
Basically we mark all requests as pending until a block number is returned from the EventSentry.init RPC call. Once we get a blockNumber, the whole machinery starts.
This accounts for the edge case "What if two or more blocks are mined between the 2-second polling period?".
This also implements the EventySentry.watch API a bit more honestly, as the old one ignored the LogFilter's fromBlock and toBlock fields, and mutated them to watch the latest block off the bat. This implementation will allow you to grab arbitrary block ranges, as well as continuously poll the latest blocks.
All kinds of tricky considerations arose as the re-implementation moved along.
Basically we mark all requests as
pendinguntil a block number is returned from theEventSentry.initRPC call. Once we get a blockNumber, the whole machinery starts.This accounts for the edge case "What if two or more blocks are mined between the 2-second polling period?".
This also implements the
EventySentry.watchAPI a bit more honestly, as the old one ignored theLogFilter'sfromBlockandtoBlockfields, and mutated them to watch the latest block off the bat. This implementation will allow you to grab arbitrary block ranges, as well as continuously poll the latest blocks.