Skip to content

Traffic-Based App Rewards: Add counters to RewardComputationTrigger#4860

Merged
adetokunbo merged 7 commits into
adetokunbo/feature-cip-104-scan-computationfrom
adetokunbo/cip-104-add-compute-rewards-counters
Apr 12, 2026
Merged

Traffic-Based App Rewards: Add counters to RewardComputationTrigger#4860
adetokunbo merged 7 commits into
adetokunbo/feature-cip-104-scan-computationfrom
adetokunbo/cip-104-add-compute-rewards-counters

Conversation

@adetokunbo
Copy link
Copy Markdown
Contributor

@adetokunbo adetokunbo commented Apr 7, 2026

Fixes #4634
Follow-up to this comment in #4420
Stacked on #4847 #4859 that's currently being reviewed
Tracked in #4384

Pull Request Checklist

Cluster Testing

  • If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
  • If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
  • If a logical synchronizer upgrade test is required (from canton-3.5), comment /lsu_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

  • Include any change that might be observable by our partners or affect their deployment in the release notes.
  • Specify fixed issues with Fixes #n, and mention issues worked on using #n
  • Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

  • Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

Copy link
Copy Markdown
Contributor

@meiersi-da meiersi-da left a comment

Choose a reason for hiding this comment

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

Looks good overall. Thanks.

I'll leave the final review and approval to @rautenrieth-da

Comment on lines +900 to +901
// TODO(#4645): read num_activity_records_in_round from app_activity_round_totals
// instead of using a separate count query
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm slightly uneasy about the join below, which is a potential performance snag.

Any chance to change the order of PR's and fix 4645 first?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Or at least make sure to solve #4645 as a fast follower.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'll merge this after #4859 is merged which addresses #4645. When this PR is rebased on that, I'll be able fix this comment and remove the TODO

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Note that if you rebase this PR on top of #4859 and change the base of your PR to #4859, then you can do the changes already now; and GH will automatically change the base of your PR once #4859 is merged.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Done, PTAL

private val prefix: MetricName =
SpliceMetrics.MetricsPrefix :+ "scan" :+ "reward_computation"

val activePartiesCount: Counter = metricsFactory.counter(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Counters are reset on each application start, so they are mostly useful for observing the rate of change in the metric (i.e., active parties added/removed per second). Is this what we are interested in?

I would have expected that we want to know what the party count was at any given time. For this, a Gauge sounds like a better metric.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That's a good point. I originally pointed towards counters, but it seems that converting all of them to Gauge's makes more sense. They make it easy to alert on these metrics being unexpectedly high or low (e.g., no reward issued for the last hour).

Let's switch to gauges then.

@adetokunbo : note that gauges need to be closed. Please register their closing methods as it is done in other metrics classes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fixed

@adetokunbo adetokunbo changed the base branch from adetokunbo/cip-104-add-compute-hashes-save-batched-hashes to adetokunbo/cip-104-expand-get-reward-accounting-activity-totals-response April 9, 2026 11:41
@adetokunbo adetokunbo force-pushed the adetokunbo/cip-104-add-compute-rewards-counters branch 2 times, most recently from ba83d25 to cf42fda Compare April 9, 2026 11:46
@adetokunbo adetokunbo force-pushed the adetokunbo/cip-104-add-compute-rewards-counters branch from cf42fda to 65d5745 Compare April 9, 2026 11:52
Copy link
Copy Markdown
Contributor

@rautenrieth-da rautenrieth-da left a comment

Choose a reason for hiding this comment

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

Thanks!

Base automatically changed from adetokunbo/cip-104-expand-get-reward-accounting-activity-totals-response to adetokunbo/feature-cip-104-scan-computation April 9, 2026 13:55
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Tim Emiola <adetokunbo@emio.la>
@adetokunbo adetokunbo force-pushed the adetokunbo/cip-104-add-compute-rewards-counters branch from 65d5745 to b34e7f8 Compare April 9, 2026 14:27
adetokunbo added a commit that referenced this pull request Apr 12, 2026
@adetokunbo adetokunbo merged commit a2adaea into adetokunbo/feature-cip-104-scan-computation Apr 12, 2026
125 of 127 checks passed
@adetokunbo adetokunbo deleted the adetokunbo/cip-104-add-compute-rewards-counters branch April 12, 2026 23:19
adetokunbo added a commit that referenced this pull request Apr 13, 2026
adetokunbo added a commit that referenced this pull request Apr 13, 2026
adetokunbo added a commit that referenced this pull request Apr 14, 2026
adetokunbo added a commit that referenced this pull request Apr 16, 2026
adetokunbo added a commit that referenced this pull request Apr 17, 2026
rautenrieth-da added a commit that referenced this pull request Apr 17, 2026
Merges the feature branch for the scan computation part of CIP-104, consisting of the following individual PRs:

* Add app activity computation store and schema (#4372)
* Compute aggregateActivityTotals, add ComputeAppRewardTrigger, expose new endpoints (#4420)
* Adds computeRewardTotals to DbScanAppRewardsStore (#4639)
* Add DB versions of Splice.Amulet.CryptoHash (#4662)
* Expand GetRewardAccountingActivityTotalsResponse (#4859)
* Add counters to RewardComputationTrigger (#4860)
* Compute Hashes (#4847)


Signed-off-by: Tim Emiola <adetokunbo@emio.la>
Signed-off-by: Timothy Emiola <adetokunbo@users.noreply.github.com>
Co-authored-by: Simon Meier <simon@digitalasset.com>
Co-authored-by: Robert Autenrieth <31539813+rautenrieth-da@users.noreply.github.com>
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.

3 participants