go/txsource: commission schedule amendments workload

[ptrus]

Changing commission schedule workload, part of: #2506

TODO:

• minor todo's see code comments

[codecov]

Codecov Report

Merging #2766 into master will increase coverage by 0.25%.
The diff coverage is 76.57%.

@@            Coverage Diff             @@
##           master    #2766      +/-   ##
==========================================
+ Coverage   62.99%   63.25%   +0.25%     
==========================================
  Files         388      389       +1     
  Lines       36828    37047     +219     
==========================================
+ Hits        23200    23433     +233     
+ Misses      10661    10640      -21     
- Partials     2967     2974       +7     

Impacted Files	Coverage Δ
...oasis-node/cmd/debug/txsource/workload/workload.go	67.07% <ø> (ø)
go/staking/api/api.go	71.42% <ø> (ø)
go/consensus/tendermint/staking/staking.go	69.37% <60.00%> (-0.31%)	⬇️
go/staking/api/grpc.go	58.47% <64.70%> (+0.38%)	⬆️
...sis-node/cmd/debug/txsource/workload/commission.go	77.43% <77.43%> (ø)
go/consensus/tendermint/apps/staking/query.go	73.17% <100.00%> (+1.37%)	⬆️
go/staking/api/commission.go	98.66% <100.00%> (ø)
go/worker/common/host/interface.go	38.46% <0.00%> (-15.39%)	⬇️
...ompute/txnscheduler/algorithm/batching/batching.go	78.66% <0.00%> (-6.67%)	⬇️
go/worker/compute/txnscheduler/committee/node.go	62.34% <0.00%> (-4.02%)	⬇️
... and 28 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea2c74d...f0da05c. Read the comment docs.

[kostko]

Wouldn't it be better if the CLI argument to configure the runtime ID would be part of the runtime workload definition?

[ptrus]

Wouldn't it be better if the CLI argument to configure the runtime ID would be part of the runtime workload definition?

yeah (also probably ment for: #2759 :) )

[kostko]

Oops yeah, sorry I replied to the wrong e-mail :(

[pro-wh]

I want to know about the schedule pruning. Where is that done?

[pro-wh]

I don't see that we're checking for steps that would be pruned

[ptrus]

We aren't checking for steps that would be pruned. We are checking for existing steps that won't get amended by the amendment that we are making (since the earliest step in the amendment we are submitting will be at nextAlignedBoundChangeEpoch, existing steps for epochs smaller than it (and greater than current epoch) will be kept).

[ptrus]

we check for steps that will get overridden here:
https://github.com/oasislabs/oasis-core/pull/2766/files#diff-569acfc539454f2a192a525f1dbbb355R190-R197

[pro-wh]

link seems to be out of date

[pro-wh]

We aren't checking for steps that would be pruned.

Shouldn't we though? Because we can make the amendment longer if we take that into account

[pro-wh]

and the comment mentions that it only counts steps that wouldn't be pruned. but the code counts steps that would be pruned too

[ptrus]

oh i think i know what you're saying, so the existingCommissionSchedule obtained by account.Escrow.CommissionSchedule could itself contain non pruned steps (meaning contain more than one past step with epoch.Start<currentEpoch) - since we actually only prune it on amendments and not automatically on every epoch.

I don't think that can actually happen at the moment since we are constantly amending schedules, the existing schedules should get pruned more or less on every epoch, but nevertheless i'll do pruning on the obtained existingCommissionSchedule to cover the case.

[pro-wh]

I don't think that can actually happen at the moment since we are constantly amending schedules, the existing schedules should get pruned more or less on every epoch

ah yeah good point

[pro-wh]

lg thanks for the changes

[ptrus]

thanks for the reviews