2019-10-29 22:51:58 +03:00
|
|
|
:: eth-watcher: ethereum event log collector
|
|
|
|
|
::
|
|
|
|
|
=, able:jael
|
|
|
|
|
|%
|
|
|
|
|
+$ config
|
eth-watcher: separate timeout from refresh-rate
Previously, when the refresh-rate timer activated, and the thread from
the previous activation was still running, we would kill it and start
a new one. For low refresh rates, on slower machines, nodes, or network
connections, this could cause the update to never conclude.
Here we add a timeout-time to eth-watcher's config. If the refresh-rate
timer activates, and a thread exists, but hasn't been running for at
least the specified timeout-time yet, we simply take no action, and wait
for the next refresh timer.
Note that we opted for "at least timeout-time", instead of killing &
restarting directly after the specified timeout-time has passed, to
avoid having to handle an extra timer flow.
In the +on-load logic, we configure the timeout-time for existing
watchdogs as six times the refresh-rate. We want to set
azimuth-tracker's timeout-time to ~m30, and don't care much about other,
less-likely-to-be-active use cases of eth-watcher.
2020-04-01 13:41:04 +03:00
|
|
|
$: :: url: ethereum node rpc endpoint
|
|
|
|
|
:: eager: if true, give logs asap, send disavows in case of reorg
|
|
|
|
|
:: refresh-rate: rate at which to check for updates
|
|
|
|
|
:: timeout-time: time an update check is allowed to take
|
|
|
|
|
:: from: oldest block number to look at
|
|
|
|
|
:: contracts: contract addresses to look at
|
|
|
|
|
:: topics: event descriptions to look for
|
|
|
|
|
::
|
|
|
|
|
url=@ta
|
2019-12-09 22:41:01 +03:00
|
|
|
eager=?
|
2019-11-28 18:46:07 +03:00
|
|
|
refresh-rate=@dr
|
eth-watcher: separate timeout from refresh-rate
Previously, when the refresh-rate timer activated, and the thread from
the previous activation was still running, we would kill it and start
a new one. For low refresh rates, on slower machines, nodes, or network
connections, this could cause the update to never conclude.
Here we add a timeout-time to eth-watcher's config. If the refresh-rate
timer activates, and a thread exists, but hasn't been running for at
least the specified timeout-time yet, we simply take no action, and wait
for the next refresh timer.
Note that we opted for "at least timeout-time", instead of killing &
restarting directly after the specified timeout-time has passed, to
avoid having to handle an extra timer flow.
In the +on-load logic, we configure the timeout-time for existing
watchdogs as six times the refresh-rate. We want to set
azimuth-tracker's timeout-time to ~m30, and don't care much about other,
less-likely-to-be-active use cases of eth-watcher.
2020-04-01 13:41:04 +03:00
|
|
|
timeout-time=@dr
|
2019-10-29 22:51:58 +03:00
|
|
|
from=number:block
|
|
|
|
|
contracts=(list address:ethereum)
|
|
|
|
|
=topics
|
|
|
|
|
==
|
|
|
|
|
::
|
|
|
|
|
+$ loglist (list event-log:rpc:ethereum)
|
|
|
|
|
+$ topics (list ?(@ux (list @ux)))
|
2019-11-12 08:36:32 +03:00
|
|
|
+$ watchpup
|
|
|
|
|
$: config
|
|
|
|
|
=number:block
|
|
|
|
|
=pending-logs
|
|
|
|
|
blocks=(list block)
|
|
|
|
|
==
|
|
|
|
|
::
|
|
|
|
|
:: disavows: newest block first
|
|
|
|
|
+$ disavows (list id:block)
|
|
|
|
|
+$ pending-logs (map number:block loglist)
|
2019-10-29 22:51:58 +03:00
|
|
|
::
|
|
|
|
|
+$ poke
|
|
|
|
|
$% :: %watch: configure a watchdog and fetch initial logs
|
|
|
|
|
::
|
|
|
|
|
[%watch =path =config]
|
|
|
|
|
:: %clear: remove a watchdog
|
|
|
|
|
::
|
|
|
|
|
[%clear =path]
|
|
|
|
|
==
|
|
|
|
|
::
|
|
|
|
|
+$ diff
|
2019-10-30 20:44:34 +03:00
|
|
|
$% :: %history: full event log history, oldest first
|
2019-10-29 22:51:58 +03:00
|
|
|
::
|
|
|
|
|
[%history =loglist]
|
|
|
|
|
:: %log: newly added log
|
|
|
|
|
::
|
|
|
|
|
[%log =event-log:rpc:ethereum]
|
|
|
|
|
:: %disavow: forget logs
|
|
|
|
|
::
|
|
|
|
|
:: this is sent when a reorg happens that invalidates
|
|
|
|
|
:: previously-sent logs
|
|
|
|
|
::
|
|
|
|
|
[%disavow =id:block]
|
|
|
|
|
==
|
|
|
|
|
--
|
