Open michaeldjeffrey opened 2 months ago
let (_, rewards) = tokio::join!(
// run rewards for poc and dc
rewarder::reward_poc_and_dc(
&pool,
&hex_boosting_client,
&mobile_rewards_client,
&speedtest_avg_client,
&epoch,
dec!(0.0001)
),
receive_expected_rewards(&mut mobile_rewards)
);
When I tried to run rewarder::reward_poc_and_dc
by itself, then receive the rewards, the test would never finish. I do not understand why.
let (_, rewards) = tokio::join!( // run rewards for poc and dc rewarder::reward_poc_and_dc( &pool, &hex_boosting_client, &mobile_rewards_client, &speedtest_avg_client, &epoch, dec!(0.0001) ), receive_expected_rewards(&mut mobile_rewards) );
When I tried to run
rewarder::reward_poc_and_dc
by itself, then receive the rewards, the test would never finish. I do not understand why.
This will be because the filesink writer awaits a oneshot response to indicate the file/s have been written to disk. If you do not call receive_expected_rewards
then this oneshot never gets returned and thus the rewarder's writer will wait indefinitely. See link below for an example of the oneshot response being sent from the tests receive handler: https://github.com/helium/oracles/blob/main/mobile_verifier/tests/common/mod.rs#L35
Other than clippy not being happy, this all looks good to me.
https://github.com/helium/proto/pull/401 https://github.com/helium/helium-program-library/pull/634
BoostedHexInfo.device_type
addedBecause legacy boosts exists (
NULL
in the database mapping toBoostedHexDeviceType::All
), a single hex can now be considered boosted more than a single time.BoostedHexes
carriesn
number of boosts per cell.When asking for the current multiplier of a hex, the device type in question must be provided. All boosts that apply are combined.
parse_boosted_hex_info_from_database
testBecause this project does not control the metadata db, I wanted to make sure
BoostedHexDeviceType
would correctly serialize as a part ofBoostedHexInfo
.Looking at the helium-program-library implementation it wasn't clear how
DeviceTypeV0
would make it's way into the database. There is a similar fieldDeviceType
inmobile_hotspot_infos
that has also uses a rust enum that is present as ajsonb
column.If that assumption turns out to be false, updating the test should lead us to the glory of correctly serializing
device_type
.BoostedHexes
and "expired boosts"@bbalser and I talked about
BoostedHexes
only ever containing non-expired boosts.Ideally, that would occur at the level of mobile-config when boosted hexes are being streamed out of the db. However, boosted hexes do not have a
end_ts
field that is easily queryable, and I'm not comfortable at this point in time putting that much math into a sql query.I tried at each next level. In the end, I decided to give up on that goal for this PR. Tests using
BoostedHexes
directly would not have a way to enforce the contract of only holding actively boosted hexes, and now didn't feel like the correct time to dive into those tests to find a way they could.