[Draft] Auto reassignment fail#2046
Conversation
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
| stakeholder, and indeed the _explicit_ `reassign` submitted by Bob always | ||
| worked. The blocker is the **`TokenRules` factory**, whose only stakeholder is | ||
| `admin`. With a **separate `TokenAdmin` party**, the submitter (Bob) is **not** a | ||
| stakeholder of `TokenRules`, so Canton refuses to reassign it automatically. |
There was a problem hiding this comment.
Yes, the unreassignability of the TokenRules is why I'm pushing for guidelines where the workflows tell the token standard registry what the target synchronizer is. See this conversation: #1622 (review)
For that to work cleanly we'll need a small amendment to the token standard off-ledger APIs. However, until then we can funnel the information in an additional field in the choiceArgument submitted to the factory endpoints; e.g. a top-level _targetSynchronizerId field, which you then parse in the TestTokenV1 registry handlers.
There was a problem hiding this comment.
I do not understand this :-(
I tried to play around - but do not get how would this additional field help in fundamental problem, that contract cannot be reassigned automatically
There was a problem hiding this comment.
The trick is that the TestTokenV1 registry maintains TokenRules contract on every synchronizer it supports and selects the right one based on the communicated target synchronizer. This guarantees that TokenRules contracts never need to be reassigned by the client submitting a token standard action.
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
meiersi-da
left a comment
meiersi-da
left a comment
There was a problem hiding this comment.
Some comment from my review to get context on what might be failing,
| return { | ||
| appUserSdk, | ||
| appProviderSdk, | ||
| appAliceSdk, |
There was a problem hiding this comment.
side question: why is this "app"AliceSdk? What is "app'y" about this? I'd have expected "aliceSdk".
| @@ -46,18 +46,18 @@ export async function aliceSelfTransferToApp( | |||
|
|
|||
| // The settled holding lands on the global synchronizer; move it to the | |||
| // app-synchronizer before self-transferring there (mirrors Bob's flow). | |||
There was a problem hiding this comment.
app-synchronizer vs testTokenSynchronizerId ... seems inconsistent...
| @@ -131,7 +140,18 @@ const testTokenAllocationDisclosed = { | |||
| synchronizerId: '', | |||
| } | |||
There was a problem hiding this comment.
This does not match what we would expect to happen in reality. The trading app would be listening on their participant node to observe the allocation and use it only then. I'd suggest to implement the code here such that you wait for it to appear on the participant node used for the submission of the settlement.
| @@ -152,20 +172,20 @@ try { | |||
| await bobSelfTransferToApp(setup, logger) | |||
There was a problem hiding this comment.
What is that? Why do we have to wait for a self-transfer?
| @@ -152,20 +172,20 @@ try { | |||
| await bobSelfTransferToApp(setup, logger) | |||
| logger.info('Contracts after settlement failure (compensation applied):') | |||
There was a problem hiding this comment.
This does not match what we'd expect to happen on a settlement failure. The default would be that the settlement venue tries again, and if they fail to do so, they would cancel the allocations that exist.
| aliceTokenNamespace, | ||
| bobTokenNamespace, |
There was a problem hiding this comment.
using these two SDK's feels wrong. It should be only the trading app that uses their access to their participant node to build the command!
There was a problem hiding this comment.
there is only one sdk "handle" used (tradingAppSdk)
I see. xyzTokenNamespace are actually nod needed here
| // allocation-v1 API (instead of hard-coding an empty context). | ||
| const testTokenExecCtx = | ||
| await tokenNamespaceAppProvider.allocation.context.execute({ | ||
| const testTokenExecCtx = await bobTokenNamespace.allocation.context.execute( |
There was a problem hiding this comment.
here as well: use the tradingApp's SDK to fetch this information.
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
2 participants
No description provided.