feat(argus): internal interfaces and shared memory model #2682
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
apps/argus/src/adapters/types.rs
Outdated
| async fn subscribe_to_price_updates(&self, feed_ids: &[PriceId]) -> Result<()>; // TODO: return a stream | ||
| } | ||
|
|
||
| // TODO: find a different home for these (public SDK) |
There was a problem hiding this comment.
There was a problem hiding this comment.
yep! will use the types in there
| pyth_price_client: Arc<dyn ReadPythPrices + Send + Sync>, | ||
| backoff_policy: ExponentialBackoff, | ||
| request_rx: Mutex<Option<mpsc::Receiver<PushRequest>>>, | ||
| request_tx: mpsc::Sender<PushRequest>, |
There was a problem hiding this comment.
how are you going to share it with others?
There was a problem hiding this comment.
It will be shared with other services' new() functions. Only the Controller uses it right now, so we could have just returned a reference to this service directly, but the channel is helpful to decouple the two imo.
| subscription_state: Arc<SubscriptionState>, | ||
| pyth_price_state: Arc<PythPriceState>, | ||
| chain_price_state: Arc<ChainPriceState>, |
There was a problem hiding this comment.
ah so instead of relying on the magic of type inferences you decided to literally pass the states around. good idea!
There was a problem hiding this comment.
it's less robust isolation, but a lot simpler to implement and reason about 😄
There was a problem hiding this comment.
i recommend moving some of these in to the files to reduce indirection if they are only used in one place.
| ) -> Result<()> { | ||
| tracing::info!("Starting keeper for chain {}", chain_name); | ||
|
|
||
| // TODO: create a contract with a WS provider if geth_rpc_wss was provided |
There was a problem hiding this comment.
you probably don't have to worry about the wss feature -- we don't even use this in fortuna. you can probably delete this feature entirely
There was a problem hiding this comment.
Ah okay cool. Figured it would be nice to primarily stream in price updates and only poll as a backup, but I can imagine wss support/reliability is spotty with RPCs.
apps/argus/src/command/run.rs
Outdated
| let state = Arc::new(ArgusState::new()); | ||
|
|
||
| let hermes_client = Arc::new(HermesClient); | ||
| let subscription_poll_interval = Duration::from_secs(60); |
There was a problem hiding this comment.
in the future: please make these configurable from the config file
There was a problem hiding this comment.
Yep definitely
| state.chain_price_state.clone(), | ||
| ); | ||
|
|
||
| let pyth_price_service = PythPriceService::new( |
There was a problem hiding this comment.
do you really want to instantiate a separate one of these per chain? I think you could probably run a single thread that listens to the hermes websocket and streams the prices to check across all chains.
There was a problem hiding this comment.
Yeahh i had the same thought, this was the path of least resistance since we can just replace the tracked feed ID set per chain. Later I'll extract this out to be a single thread with redundant connections and the like.
Summary
Skeleton for Argus. Defines code organization, internal interfaces, and sets up a services + shared memory model.
Previously I had explored implementing Argus with an actor model (#2659 ), but after useful feedback, it feels more straightforward to go with a more standard shared memory approach.
We still keep the isolation and separation of concerns from the actor model, but without the message-box concept for IPC.
I also considered implementing the trait system from Hermes to gate access to certain State objects behind traits, but found it didn't add much value here.
Services
Services are long-running processes (tokio tasks) responsible for executing business logic and keeping relevant States up-to-date (e.g. via polling or subscribing to data sources via Adapters.)
State
The State objects hold the state for Argus for a specific blockchain and expose them to Services via read/write APIs, wrapping the underlying data structure with synchronization primitives like RwLock and DashMap.
Adapters
Interactions with external services like Hermes and the blockchain are modeled by the traits in adapters/types.rs. These traits are used by the actors, and are implemented by hermes.rs, contract.rs, etc.
How has this been tested?
Not tested yet. Next up is wiring up the Controller's main update loop to mock implementations, and ensuring the actor communication works. Then, we will implement individual actor logic, and eventually wire it up to the blockchain instead of mock adapters.