During local testing with canton pruning, it seems that all created events (that is not archived) will be moved to “pruned-offset”. Is this correct?
For example, we are pruning offset “0000…f” and there’s no archived event before “0000…f”, does all created events before “0000…f” gets moved to “0000…f”?
If above is correct, does that mean this particular offset now maps to multiple transactions?
Thanks in advance!
One more small question,
From local testing, it looks like after pruning when we do getActiveContractSet
the event order seems to be preserved.
E.g.
Before pruning ====== (assuming no archive happens)
Tx1: (event1) – offset 1
Tx2: (event2, event3) – offset2
Tx3: (event4, event5) – offset 3
After pruning at offset3 =======
when we call getActiveContractSet
the event will be delivered in below order:
event1 → event2 → event3 → event4 → event5
We would like to double check if that’s the right assumption.
Thank you!
Offsets of all active contracts (concretely speaking the offsets of the corresponding create events) are preserved in pruning. So if a create event of an active contract was communicated at offset 00005 before the pruning, the event will still sit at offset 00005 afterwards.
The ACS user experience remains unchanged before and after the pruning, With the exception that it is forbidden to ask for ACS snapshots predating the pruning. If you ask for a snapshot at an earlier offset you will get a FAILED_PRECONDITION error back.
Likewise if the transaction(-tree) stream is requested with a “begin” offset predating pruning, similar error will be returned.
2 Likes