* add /v2/updates/price/latest endpoint
* Update data type in BinaryPriceUpdate struct
* support compressed update data
* Update API endpoint in index.rs
* Update hermes/src/api/types.rs
Co-authored-by: Ali Behjati <bahjatia@gmail.com>
* move to v2 module and address comments
* address more comments
* address more comments
---------
Co-authored-by: Ali Behjati <bahjatia@gmail.com>
Openmetrics specification expects its own content-type instead of plain
text. I didn't set it before as Prometheus still accepts text format but
apparently there are some scrapers (like datadog) that decide
dynamically what format to use for parsing based on the content type and
our format follows Openmetrics specification. Prometheus should be able
to parse it but weirdly it didn't work in our situation. An example of
inconsistency is how counters are represented. In Openmetrics
specification the metric name is appended by `_total` whereas normal
prometheus just uses the metric name.
Before this change, there was a lock for each message and it could
cause the updateData for multiple ids have 2 updates (because of the
race with the thread updating the states). This change adds a RwLock
which makes sure that when the entire message state is updating,
no one can read from it while allowing concurrent reads in other
occasions.
This check will make rejects faster (and block invalid requests
to benchmarks). The other benefit is that we can log the
errors from the get_price_feeds_with_update_data since it should
not fail anymore.
In some cases arguments are passed and renamed (see `api_addr -> rpc_addr`) or
are unnecesarily converted (see `api_addr.to_string()` -> `api_addr.parse()`.
In the future, we are likely to add many more arguments to Hermes as well, so
this commit moves them into a separate struct which is forwarded throughout the
application instead.
The struct's are cloned, but only happens during launch of a hermes service
component so the cost doesn't matter.
Fix hermes construct_update_data to support generating update_data
for more than 255 messages. This is very unlikely to happen in normal
cases but the way WS <> store interact can cause this to happen when
a WS client subscribes to all price feeds.
Daniel Chew
Dev Kalra
Ali Behjati
Reisen