Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix reward amount and add test for reward construction #26

Merged
merged 6 commits into from Aug 16, 2022

Conversation

vihu
Copy link
Member

@vihu vihu commented Aug 16, 2022

Summary

This PR has two major changes:

  1. It introduces async-trait with potentially questionable usage for find_owner for follower_service. The reason is that async closures are not part of stable rust, just yet. This is more of a hacky workaround to allow setting a default_owner and just ignore looking up follower_service for testing.

  2. This fixes the emitted rewards in construct_rewards to correct evaluate the bones. We were sending Mobile directly instead of re-converting it back to bones.

TODO

  • Use some other known test keypair and re-verify the constructed txn hash

@vihu vihu requested a review from madninja August 16, 2022 03:56
@vihu vihu requested a review from maplant August 16, 2022 04:03
Copy link
Member

@madninja madninja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The async-trait is fine.. it's used by Tokio quite a bit internally, which is why you can import it using "*". How you're using it is definitely not how I was expecting though

@@ -18,6 +19,35 @@ pub struct FollowerService {
client: FollowerClient,
}

#[async_trait]
pub trait FollowerServiceTrait {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename to OwnerResolver. I prefer traits to be named after the thing they do and not have "Trait" in their name

async fn find_owner(
&mut self,
address: &PublicKey,
test_owner: Option<PublicKey>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this is a neat trick, I think the right approach would be to have a different imp for this trait that is the Test version of the OwnerResolver right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I much prefer the way you did it. I'll remember it from now on.

@@ -167,20 +168,17 @@ pub async fn construct_rewards(
counter: Counter,
model: Model,
emitted: Emission,
default_owner: Option<PublicKey>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so why are you not passing in the OwnerResolver here?


let mut reward_acc = 0;
let mut reward_acc = dec!(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I see what you did here.. why aren't you using Mobile here instead of a new Decimal with a 1 multiplier? To avoid the Option? looks cleaner I think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, also, I didn't really want to impl Div and AddAssign for Mobile. The u64 does get constructed from Mobile once the rewards have been accumulated so it should preserve the 8 decimal precision afaict. Will try to test it more.


let (txn, txn_hash_str) = construct_txn(&loaded_kp, SubnetworkRewards(rewards), 1000, 1010)
// TODO: read key from some test env
let kp = load_from_file("/tmp/reward_server_keys").expect("unable to load keypair");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inline them as bytes or using the macros in the base64 crate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, yes. I'll do that.

madninja and others added 5 commits August 16, 2022 07:43
Don’t try to work around the trait with default values.. Introduce a FixedOwnerResolver for test cases
simpler fetch commands
- Fix unnest query
- Fix parameter binding for update_all query
- Stick to lowercase for migrations
@madninja madninja merged commit 5ac6821 into main Aug 16, 2022
@madninja madninja deleted the rg/reward-server-testing branch August 16, 2022 22:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants