Some contracts are not being created when exercising a choice

G-d willing

I am seeing a very strange behavior in Daml.
In the navigator - I am exercising a choice which create 3 contracts. However, only the first one is created.
But when I am exercising it through a scenario, all is working fine.

Did anyone experience such a thing?

@cohen.avraham Do the contracts have the same entitlements?

G-d willing

Hi @Leonid_Rozenberg, thanks for your response, regarding your question, of course, I set the contracts with the same values as in the script.
I was checking that several times and with no luck.

Here is the code from the choice I am running:

nonconsuming choice AcceptBidInvitationFromIssuer: ContractId IssuerBankerBidRelationship
      with
        bidIdentifier: Text
      controller owner
        do  
          (invitationCid, invitation) <- fetchByKey @BidInvitationOfferToBanker (issuer, owner, bidIdentifier)
          assertMsg "The banker dealer does not match" (invitation.banker == owner)
          assertMsg "The wrong bid was found" (invitation.bidIdentifier == bidIdentifier)
          relationshipCid <- exercise invitationCid AcceptBidInvitationOfferToBanker

          forA_ investors $ \invest ->
            create BidInvitationOfferToInvestor with interestRate=invitation.interestRate,periodInMonths=invitation.periodInMonths,banker=owner; investor=invest,expiryDate=invitation.expiryDate; amount=invitation.amount, minProposal=invitation.minProposal,..

          exercise relationshipCid InitializeBidAcceptance
          return relationshipCid

As said, the first contract in the following line is created:

          relationshipCid <- exercise invitationCid AcceptBidInvitationOfferToBanker

However, the rest is not created in Navigator. And I used debug just to make sure that the list of “investors” is not empty (actually there are 4 investors in the list).

Here is a screenshot of the script form the Visual Code:

And here is the screenshot from the Navigator, where the contract “BidInvitationOfferToInvestor”:

Hi @cohen.avraham,

Scripts running in Daml Studio (the VSCode editor) do not run against an external ledger, they run against an internal in-memory one. Therefore, there is no link between the state of your ledger in the IDE and the state presented by Navigator (which is connected to a real, separate ledger).

The most plausible explanation here is that, in your scripts, you set up investors as a list with four elements, but, in the “real” ledger, it’s an empty list.

Could you perhaps share a screenshot of the Navigator showing the details of the relevant contract? (From your code snippet it looks like investors is a property of the contract on which AcceptBidInvitationFromIssuer is a choice, but I can’t see which template that is.)

Sure thing @Gary_Verhaegen , the AcceptBidInvitationFromIssueris choice of the Banker template I created.
Here is the Banker template (without its choices):

template Banker
  with
    issuer: Party
    owner: Party
    investors: [Party]
  where
    signatory owner
    observer investors

I have a script running (which is defined in the daml.yaml file) that sets the list of the investors to the banker:

  bankLeumiBrokerCid <- submit leumiBankBroker do
    exerciseCmd bankLeumiBrokerCid OnboardInvestor with investor=meitavDash
  bankLeumiBrokerCid <- submit leumiBankBroker do
    exerciseCmd bankLeumiBrokerCid OnboardInvestor with investor=migdal
  bankLeumiBrokerCid <- submit leumiBankBroker do
    exerciseCmd bankLeumiBrokerCid OnboardInvestor with investor=menura
  bankLeumiBrokerCid <- submit leumiBankBroker do
    exerciseCmd bankLeumiBrokerCid OnboardInvestor with investor=harel

And you can see from the following screenshot that the list of investors is not empty at the navigator:

Looking forward to your answer…

Thanks!

Next thing I would check, then, is that all of those are proper parties initialized in the ledger Navigator runs against. I don’t think we check that a party exists when it is just added to a list.

To that end, can you confirm that, in the Navigator:

  1. you can create a single-signatory contract for each of those investors.
  2. you can observe the consequences of the exercise relationshipCid InitializeBidAcceptance line.

Regarding the other things you mentioned, like creating a single-signatory contract, well, it was created - you can see that in my first screenshot from the navigator.
Well, all the bankers and investors are listed on the login screen of the navigator:

And for the investors, they are initialized in the main script as well:

  meitavDash <- allocatePartyWithHint "Meitav Dash" (PartyIdHint "Meitav Dash")
  migdal <- allocatePartyWithHint "Migdal" (PartyIdHint "Migdal")
  menura <- allocatePartyWithHint "Menura" (PartyIdHint "Menura")
  harel <- allocatePartyWithHint "Harel" (PartyIdHint "Harel")```

Apologies if I’m being dense here, but I’m not seeing an example of a single-signatory contract per investor in any of your screenshots.

While reviewing the screenshots, however, I did notice that, in the IDE screenshot you shared, all of those BidInvitationOfferToInvestor contracts are archived. I suspect something else happens after their creation to archive them, either the InitializeBidAcceptance choice or the rest of your init script.

Archived contracts are not shown in Navigator.

Do you have any reason to believe these contracts should not be archived?

Here is an example of a single-signatory contract of the investor

The thing is, the behavior is not consistent. Sometimes it does create the invitation contract and sometimes it doesn’t.
I can share with you the entire code of what I did, and you can see it for yourself. How about that?

If you feel comfortable sharing the entire code publicly here, sure. Preferably in the form of a public GitHub repo or similar.

If you don’t, and you meant to share the code privately with me only, then I’m afraid that requires a support contract with Digital Asset and you’ll have to go through our customer support ticket process (and possibly the sales team to become a customer first, depending on your current status on that front).

Hi @Gary_Verhaegenm I have opened a ticket (00001542)
Hopefully, once I will understand the problem, I will share my thoughts and mistakes from it, so other can learn as well.

1 Like