Canton ledger pruning limitation: Commitment from Counter-Participants

Questions
,
1

From the docs here:

Pruning of participants requires the participant to have received a commitment from each counter-participant with which it shares a contract. If a participant becomes defunct and stops sending commitments, pruning of the participant will not work. Therefore, before you disable a participant, please make sure that is not involved in any contract. This is a current limitation.

  1. Is this commitment received once per pruning process kickoff for all contracts shared with the counter-participants?
  2. Assuming the contracts I’m trying to prune include atleast one contract shared with your participant node, does this limitation essentially mean that I can not prune my participant node if yours goes down, and that I can never prune my participant node if yours is permanently disabled?
  3. How to ensure a participant is not involved in any contract before it is disabled?
2

Thank you for your questions:

  1. The commitments run continuously in the background as long as the set of active contracts among participant changes according to the reconciliation-interval setting (by default once every 60 seconds) defined on the domain “linking” any two participants.
  2. Correct, in order to not break non-repudiation, participants only permit pruning of contracts whose activeness has been certified with “counter-participants”.
  3. Examining the active contracts set to ensure that it is empty would be one way. Ideally active contracts would be moved to other participants. There is a separate page that describes how to “migrate parties” which I will look up and back to you on.
1 Like
3

Hello again, Mr. Mannoroth:

As a follow-up on question 3, here is guidance on how one might go about moving parties along with their contracts to another participant: Identity Management — Daml SDK 2.6.1 documentation

Thanks,
– Oliver

4

Thanks @oliverse! Re #3, I meant it in the context of #2 and the last line of the doc section I have referenced in my original post -
If a counter participant is disabled, I can’t prune my node as long as I have a single contract with them - I believe this is in the context of archived not active contracts as the latter are anyway not eligible to be pruned.
Based on your response in #2, my understanding is that if all my contracts before the pruning offset with the counter participant are now archived, but the counter participant has been disabled, I still can’t prune my node.

Hence, I’m asking how to migrate archived contracts that the counter participant and my node share? (The party migration link talks about migrating active not archived contracts).

5

Unfortunately the constraint highlighted in the answer to your question 2 is currently a fundamental one, so at this point there is no way to get a participant to prune if a counter-participant is permanently disabled. This shortcoming is on our roadmap to address, but I don’t have a specific timeline by which we are able to perform the corresponding work.

– Oliver

6

Thank you @oliverse for your responses!

However, I do have a few more questions on this as it seems like quite a dire situation if any one node goes down and can’t be brought back up resulting in all other counter participants in the domain never being able to prune again.

  • How would this work for cases of failover from active to passive node? Would the activeness checks also be done on the secondary node now instead of the primary that failed?

  • If I need to prune my node after another node I was transacting with failed over to its secondary, would that mean I can’t prune unless the primary is brought back up again (albeit passive?)

  • It would be imperative for us to be aware of what situations could potentially result in a participant being permanently disabled - would these typically be hardware failures, data corruption, data centre etc type of situations? Any others to be aware of?

7

Hello @Mr_Mannoroth

My colleague @Thibault is shortly going to respond to these failover-related concerns.

Thanks,
– Oliver

8

Hi @Mr_Mannoroth,

HA replicated nodes share the same state so there’s no absolute “primary”, whichever node is active will be available for activeness checks and allow pruning and other operations to execute normally.
So to be precise

Would the activeness checks also be done on the secondary node now instead of the primary that failed?

yes

  • If I need to prune my node after another node I was transacting with failed over to its secondary, would that mean I can’t prune unless the primary is brought back up again (albeit passive?)

No, you would be able to prune after the newly active node has taken over

  • It would be imperative for us to be aware of what situations could potentially result in a participant being permanently disabled - would these typically be hardware failures, data corruption, data centre etc type of situations? Any others to be aware of?

It’s difficult to give a fully exhaustive list. If by permanently you mean a catastrophic failure that would prevent recovery of the participant, your list seems reasonable. You can add to it compromise of the namespace key.

1 Like
9

Thank you for your explanations @oliverse and @Thibault!