feat(example-test-token-v1-registry): enable passing synchronizerId for allocation & transfer - #2251
Conversation
8eb11f4 to
6b6c43f
Compare
6b6c43f to
9644cbe
Compare
8e04537 to
f777673
Compare
…d for allocation & transfer instructions Signed-off-by: Mateusz Piątkowski <mateusz.piatkowski@digitalasset.com>
f777673 to
6391241
Compare
mateuszpiatkowski-da
changed the title
Signed-off-by: Mateusz Piątkowski <mateusz.piatkowski@digitalasset.com>
| (factory) => | ||
| factory.synchronizerId === synchronizerId.allocationInstruction | ||
| ) | ||
| if (syncFactory) { |
There was a problem hiding this comment.
If syncFactory is undefined, because none of factories matched synchronizerId.allocationInstruction, but fetchedFactories has at least one item, then we return fetchedFactories[0].
I think a better flow in "multi-sync mode" would be to skip returning fetchedFactories[0] if no factory matches sync id, and go straight to "...and create one otherwise" part.
| let server: Server | ||
|
|
||
| await initOperatorParty() | ||
| export const startRegistry = async ( |
There was a problem hiding this comment.
Nothing but tests calls startRegistry. Is that intentional in scope of that branch?
| }) | ||
|
|
||
| it("shouldn't do anything", async () => { | ||
| const { stopRegistry } = await import('.') |
There was a problem hiding this comment.
Now that importing index doesn't trigger any action, and start/stop has to be manually called, maybe it would be less confusing to have one static import at the beginning of the file?
| // Copyright (c) 2025-2026 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved. | ||
| // SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| export const synchronizerId = { |
There was a problem hiding this comment.
I'm suspicious of that approach to have a shared module level object with sync ids that is mutated after calling startRegistry if options?.synchronizerIds is provided, while stopRegistry doesn't reset it to empty state.
Example problematic scenario:
-startRegistry with options?.synchronizerIds -> synchronizerId modified, getAllocationFactory would check this syncs id
-stopRegistry
-startRegistry without options?.synchronizerIds -> synchronizerId from previous startRegistry still present, getAllocationFactory would check sync ids from previous startRegistry.
I would at least clear it in stopRegistry.
Or you could consider a different approach where syncIds live only inside registry instance, instead of a common module level object. Seems safer and easier to modify, i.e. if you wanted an option to have multiple instances of registry at the same time for some reason. But this is far-fetched scenario which I don't know we will ever need, so for me it's only important that you assure uninteded synchronizer ids don't appear when we didn't want them, so cleanup in stopRegistry probably would suffice.
| * @customize The registry shouldn't be responsible for vetting daml files. We're doing this for development purposes only. Feel free to remove this when constructing your own token. | ||
| */ | ||
| if (process.env.NODE_ENV === 'development') await TestToken.utils.vetDar(sdk) | ||
| await initOperatorParty(options?.operator) |
There was a problem hiding this comment.
Not sure if it's a problem, but if you startRegistry, stopRegistry and startRegistry again, it will try to allocate same party twice.
2 participants
Signed-off-by: Mateusz Piątkowski mateusz.piatkowski@digitalasset.com
Stack created with GitHub Stacks CLI • Give Feedback 💬