Use ExportPartyAcs/ImportPartyAcs for SV party replication

[OriolMunoz-da]

Fixes #3629

cluster test

[OriolMunoz-da]

https://docs.digitalasset.com/operate/3.4/howtos/operate/parties/party_replication.html#authorize-new-hosting-for-the-party

To later find the ledger offset of the topology transaction which authorizes the new hosting arrangement, take the current ledger end offset on the source participant as a starting point

The offset used before is after activation, so it didn't seem to work

[moritzkiefer-da]

Is the implementation here safe under crashes? Can I not end up in a situation where the offset is now after the topology transaction and it fails because of that?

[OriolMunoz-da]

gah, you're right. What's a safe & stable offset to use here? The offset of the contract in contracts <- dsoStore.lookupSvOnboardingConfirmedByParty(candidateParty)?

[moritzkiefer-da]

That should be safe I hope. i guess the alternative is to actually look for the topology transaction, do timestamp => offset and subtract 1? But I'd also report this to the Canton team. This just feels like pretty questionable UX to me.

[yves-da]

i guess the alternative is to actually look for the topology transaction

The ExportPartyAcs endpoint searches internally for the effective topology transaction that "activates" the party on the target participant (where the party is going to be newly hosted).
In principle, you could give an ledger offset taken from before starting the replication process. But the caveat is that the endpoint may take longer to complete, as its topology transaction search also takes longer, traversing through the ledger update stream.

What you need to do is to call that endpoint with a starting ledger offset from where it should search for the topology transaction on the ledger. – The "easiest" is to record the current ledger offset just before the topology transaction becomes effective (that is, all entities have authorized sufficiently the new party hosting).

So, definitely, you should not look up the topology transaction yourself, and then trying to map its validFrom (record time) to a ledger offset.

Unfortunately, a better UX is currently not available/possible. The ledger works with offsets, and all its APIs (external/internal) are "update stream" based. – Sadly, there is not yet a ledger API that would allow to "simply look up a topology transaction" on the ledger (hopefully it will come in the future).

If this flow is not workable:

1. Take offset o0,
2. Effective topology transaction for the new party hosting
3. ExportPartyAcs taking o0 as starting point

then we need to better understand why that not possible.

[OriolMunoz-da]

https://docs.digitalasset.com/operate/3.4/howtos/operate/parties/party_replication.html#authorize-new-hosting-on-the-target-participant

Please ensure the onboarding flag is set with requiresPartyToBeOnboarded = true.

Following the code, that ends up being the case by setting the flag here

[OriolMunoz-da]

also:

For 3.5, there's going to be a change regarding the clearance of the onboarding flag (heads-up) – but the corresponding endpoint will still exist as it is documented now. (edited)

[OriolMunoz-da]

/cluster_test

[github-actions]

Deploy cluster test triggered for Commit 0832fde8b85e5242752023aaa78233730e1ee5c6 in , please contact a Contributor to approve it in CircleCI: https://app.circleci.com/pipelines/github/DACH-NY/canton-network-internal/53440

[moritzkiefer-da]

Is the implementation here safe under crashes? Can I not end up in a situation where the offset is now after the topology transaction and it fails because of that?