-
Notifications
You must be signed in to change notification settings - Fork 54
Description
In #1021 we tried to switch from the old acs export/import endpoints to the new ones.
For the most part this seems to work ok.
However, it falls apart for hard synchronizer migrations. First, a very simplified recap of how this works.
- We set confirmationsRequestMaxRate = 0 in the topology state with an effective time of T.
- We wait until our node has caught up until record time T by checking through FetchTime and adding an additional delay afterwards.
- We then export with
force = true. This is required as T may not be considered clean otherwise.
The new endpoints don't have a force option. So we do the same process without force. But this then fails with
2025-06-06T11:53:34.916Z [⋮] INFO - o.l.s.a.a.c.ApiClientRequestLogger:DecentralizedSynchronizerMigrationIntegrationTest/config=cd425ed7/validator=aliceValidator (f7a9dadae3bf331dee5456af4d1ccc0c-DecentralizedSynchronizerMigrationTrigger--370fa4049302a734) - Request (tid:e3ccdc0d6707ea8a6c71338740ba7c10) com.digitalasset.canton.admin.participant.v30.PartyManagementService/ExportAcsAtTimestamp to 127.0.0.1:5502: failed with OUT_OF_RANGE/INVALID_ACS_SNAPSHOT_TIMESTAMP_PARTY_MANAGEMENT_ERROR(12,e3ccdc0d): The participant does not yet support serving an ACS snapshot at the requested timestamp 2025-06-06T11:51:45.258445Z on synchronizer global-domain::1220a2d9cefe...
I suspect this is essentially the same issue around the timestamp not being clean but I don't understand why we even have this check. My understanding was that the export from the ledger API does not actually have to care that Canton considers this clean. All we need is that the indexer has processed a record time equal or higher than the requested one and the periodic time proofs seem like they should produce that but I'm probably missing something.
This is not urgent from our side, the existing endpoints work ok for us but it is a blocker for Canton to remove the old endpoints.