Orchestrator Async runtime improvements

[hannydevelop]

No description provided.

[hannydevelop]

async runtime in deploy/erc20.rs has been improved to use tokio::time. Here's what I suggest, the println! in the map for result should be an info! macro since it'll be easy to pick up and users can pick the message Your ERC20 contract was not adopted, double check the metadata and try again easily when there's an error.

[hannydevelop]

continue basically terminates the current iteration, returning control to the loop head, typically continuing with the next iteration. However, continue can't be used in async block. I removed continuebecause I am usingtokio::join. This is in orchestrator/src/main_loop.rs`. This is still a work in progress, I'll edit it once I figure things out

[hannydevelop]

I changed while loop to loop in happy_path_v2.rs. I also added a match arm for Err and Ok

[hannydevelop]

The last commit is for transaction_stress_test.rs, made a mistake in the commit message. I added a loop just like happy_path.rs

[EricBolten]

Left some feedback. In particular I think I might disagree with the auditor's suggestion for the main loops, so perhaps we should discuss that.

[EricBolten]

In the old version of this loop, we could fail faster (in this case only waiting DELAY instead of ETH_ORACLE_LOOP_SPEED) and try from the beginning of the loop again. In the tokio join! model we'll always wait the full ETH_ORACLE_LOOP_SPEED before starting again. I know that the task joining model was suggested by the auditor, and it is cleaner, but probably performs worse in cases where we'd rather restart the loop. Based on the comments at the bottom around the elapsed time calculation, we might care more about performance than wall clock consistency.

[hannydevelop]

@cbrit, the problem here isn't sleep, rather it's join. With join, we have to wait the full ETH_ORACLE_LOOP_SPEED before starting again. However, the previous code had continue.

[cbrit]

@hannydevelop I know. I am suggesting that interval might be a better solution than join because it allows us to continue the loop while still making sure the loop only runs every ETH_ORACLE_LOOP_SPEED seconds if the match is a successful case.

The auditor said

using Instant::now() leads to non-exact timeouts and loop_speed because the checks are always if the elapsed time is greater or lesser than a fixed Duration"

but this is solved by interval.

As far as performance, I am not sure how it differs from join, or how much it really matters.

[hannydevelop]

In my opinion, I'll rather use timeout and sleep or return back to using Instant::now. Let's discuss this on Monday, I can try to contact the auditor for the logic behind using join in main_loop

[EricBolten]

Same use statement stuff around delay_for and Duration in happy_path and happy_path_v2 as in the earlier files in the changeset, just noting it here once rather than highlighting each instance.

[hannydevelop]

This commit: fc227ac fixes this, thank you.

[EricBolten]

Ah, what I meant was rather that we can include use std::time::Duration and then when we call sleep, just refer to it like tokio::time::sleep(Duration::from_secs(...)), since there is no ambiguity to require fully qualifying it inline.

[EricBolten]

Left some feedback on the updates.

[EricBolten]

Ah, what I meant was rather that we can include use std::time::Duration and then when we call sleep, just refer to it like tokio::time::sleep(Duration::from_secs(...)), since there is no ambiguity to require fully qualifying it inline.

[hannydevelop]

oops, last commit message is wrong: fixed conflicting files, ran cargo fmt main again