Add UI support for fund manager blacklist and dev fund coupon mint delay by zheli · Pull Request #6944 · canton-network/splice

zheli · 2026-08-24T19:29:13Z

Follow-up PR for #6793. It will fix the rest of the issue #6722, as well as #6904. It will close the milestone https://github.com/canton-network/splice/milestone/59

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 an upgrade test is required, comment /upgrade_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).

… in frontend Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

…d mintAfter with tests Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

…ingDelay Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

meiersi-da

Thanks a lot. Direction looks good.

meiersi-da · 2026-08-27T08:45:06Z

+    val developmentFundCouponAmount = BigDecimal(SpliceUtil.damlDecimal(40.0))
+    val expiresAt = CantonTimestamp.now().plus(Duration.ofDays(1))
+    val reason = "Bob has contributed to the Daml repo"
+    val mintingDelay = Duration.ofSeconds(30)


When testing aspects related to timing we usually use a TimeBased integration test, which allowS changing the clock using advanceTime without busy waiting.

However, all the logic wrt minting delays is already tested at the Daml level. So what we need to test here is that a coupon with a minting delay gets eventually minted without raising unexpected errors.

I'd suggest we set a delay of 10s, which is long enough so it would result in a retry if the minting would be attempted, but short enough so its CI cost is not egregious. I'd then add 10s extra wait time also to the eventually that checks whether the coupon gets minted.

For bonus points, I'd change the minting code once to not respect the mint after, and check what kind of errors are raised in the logs (I expect retries); and then check again with the proper filtering that these are gone.

meiersi-da · 2026-08-27T08:46:18Z

+        .futureValue
+        .trigger[CollectRewardsAndMergeAmuletsTrigger]
+
+    archiveExistingUnclaimedDevelopmentFundCoupons()


this looks fishy. We usually do test isolation by relying on fresh parties being allocated for new test instances. So if you scope your queries wrt coupons being created to the test-instance-specific party, then you have proper isolation.

meiersi-da · 2026-08-27T08:47:28Z

+    clue("The coupon is left alone while its mintAfter is in the future") {
+      always(durationOfSuccess = 10.seconds) {
+        bobWalletClient
+          .listActiveDevelopmentFundCoupons() should have size 1 withClue "bob coupons before mintAfter"
+        bobWalletClient.balance().unlockedQty shouldBe bobBalanceBefore
+      }
+      CantonTimestamp
+        .now()
+        .isBefore(mintAfter) shouldBe true withClue "still before mintAfter"
+    }


I don't think we need to test this, as that's already tested at the Daml level.

Suggested change

clue("The coupon is left alone while its mintAfter is in the future") {

always(durationOfSuccess = 10.seconds) {

bobWalletClient

.listActiveDevelopmentFundCoupons() should have size 1 withClue "bob coupons before mintAfter"

bobWalletClient.balance().unlockedQty shouldBe bobBalanceBefore

}

CantonTimestamp

.now()

.isBefore(mintAfter) shouldBe true withClue "still before mintAfter"

}

meiersi-da · 2026-08-27T08:47:43Z

+    }
+
+    clue("The coupon is collected once its mintAfter has passed") {
+      eventually(60.seconds) {


This is very expensive! Let's avoid it.

With the above suggestion, this would be 30s, as the eventually has a 20s default and we add the 10s extra from the delay to get some extra protection from flakes.

meiersi-da · 2026-08-27T08:59:34Z

      }
    }

+    "not collect a development fund coupon before its mintAfter" in { implicit env =>


For the same reason as explained above, I don't think we need an additional test, which increases both CI and maintenance cost. We just want to check that the coupons are ignored when their time is not due, and collected afterwards.

I'd suggest to restructure the existing test to do so as follows:

create two dev fund coupons: one with mintAfter = None and another one with mintAfter = Some 24h.

adjust https://github.com/bitdynamics-ab/splice/blob/860446c52b0247b6c3720bc7b7949300aad85fad/apps/app/src/test/scala/org/lfdecentralizedtrust/splice/integration/tests/WalletMintingDelegationTimeBasedIntegrationTest.scala#L591-L612 to expect to not collect the dev fund coupon that has a mintAfter

add an advanceTime(25h) afterwards and then check that the coupon with mintAfter is also collected.

meiersi-da · 2026-08-27T09:00:48Z

+
+    const result = buildAmuletRulesConfigFromChanges(changes);
+
+    expect(result.developmentFundManagerBlacklist).toEqual([]);


wdyt about setting it to null if it is emptied?

meiersi-da · 2026-08-27T09:01:46Z

-    developmentFundManagerBlacklist: null,
-    minDevelopmentFundMintingDelay: null,
+    // The frontend will never send null for developmentFundManagerBlacklist, an empty list is sent as `Some []`
+    // so that we can distinguish DSO that have not upgraded yet (they will have None for the field)


we do we need to distinguish that? My expectation was that forcing the upgrade happens by setting an actual minting delay.

meiersi-da · 2026-08-27T09:04:36Z

+  });
+
+  // Happy
+  test('treats an absent minting delay as a zero delay and still prefills mintAfter', () => {


Note that this forces the recipient to have upgraded. We generally try to avoid this. How difficult would it be to not set mintAfter if no mintingDelay is set?

meiersi-da · 2026-08-27T09:07:00Z

                />
              </Stack>
+
+              <Stack spacing={1} sx={{ flex: 1 }}>


Please add screenshots of all relevant states to the PR description to simplify review, as done here: #6387

zheli had a problem deploying to ci-forks August 24, 2026 19:29 — with GitHub Actions Error

canton-network-da assigned isegall-da, martinflorian-da, rautenrieth-da and ray-roestenburg-da Aug 24, 2026

zheli force-pushed the zheli/delay-devfund-coupon-ui/6722 branch from 10e7dd5 to 451c80d Compare August 24, 2026 19:30

zheli had a problem deploying to ci-forks August 24, 2026 19:30 — with GitHub Actions Error

zheli marked this pull request as ready for review August 24, 2026 19:30

zheli force-pushed the zheli/delay-devfund-coupon-ui/6722 branch from 451c80d to 5098ea2 Compare August 24, 2026 19:31

zheli had a problem deploying to ci-forks August 24, 2026 19:31 — with GitHub Actions Error

zheli had a problem deploying to ci-forks August 24, 2026 22:15 — with GitHub Actions Error

zheli force-pushed the zheli/delay-devfund-coupon-ui/6722 branch from b7ce42f to 5d29933 Compare August 25, 2026 06:53

zheli had a problem deploying to ci-forks August 25, 2026 06:53 — with GitHub Actions Error

zheli had a problem deploying to ci-forks August 25, 2026 08:26 — with GitHub Actions Error

zheli force-pushed the zheli/delay-devfund-coupon-ui/6722 branch from 825b414 to e4aaf32 Compare August 25, 2026 10:08

zheli had a problem deploying to ci-forks August 25, 2026 10:08 — with GitHub Actions Error

zheli added 4 commits August 26, 2026 15:32

Add developmentFunManagerBlacklist and minDevelopmentFundMintingDelay…

1da9b10

… in frontend Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

[ci] Add UI and backend support for minDevelopmentFundMintingDelay an…

4e48f1e

…d mintAfter with tests Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

[ci] Update integration test for mintAfter and minDevelopmentFundMint…

a518c88

…ingDelay Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

[ci] Fix lintng issue

860446c

Signed-off-by: Zhe Li <linuxcity.jn@gmail.com>

zheli force-pushed the zheli/delay-devfund-coupon-ui/6722 branch from e4aaf32 to 860446c Compare August 26, 2026 13:32

zheli requested a deployment to ci-forks August 26, 2026 13:33 — with GitHub Actions Waiting

meiersi-da self-requested a review August 27, 2026 08:00

meiersi-da reviewed Aug 27, 2026

View reviewed changes

Navigation Menu

Uh oh!

Add UI support for fund manager blacklist and dev fund coupon mint delay - #6944

Add UI support for fund manager blacklist and dev fund coupon mint delay#6944
zheli wants to merge 4 commits into
canton-network:staging-0.8.0from
bitdynamics-ab:zheli/delay-devfund-coupon-ui/6722

zheli commented Aug 24, 2026

Uh oh!

meiersi-da left a comment

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

meiersi-da Aug 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants


		const result = buildAmuletRulesConfigFromChanges(changes);

		expect(result.developmentFundManagerBlacklist).toEqual([]);

Uh oh!

Conversation

zheli commented Aug 24, 2026

Pull Request Checklist

Cluster Testing

PR Guidelines

Merge Guidelines

Uh oh!

meiersi-da left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants