Issues allocating parties with large number of characters

Questions
1

Hello!

We’re using the Java gRPC ledger-api bindings to allocate parties and found some issues depending on whether the partyIdHint is set or not. Here is a brief portion of the code which highlights how we are using the gRPC PartyManagementService, both with the hint and without the hint.

  PartyManagementServiceOuterClass.AllocatePartyResponse response;
            if (withPartyHint){
                response = partyManagementServiceBlockingStub.
                        allocateParty(PartyManagementServiceOuterClass.AllocatePartyRequest.newBuilder().setDisplayName(party).setPartyIdHint(party).build());
            } else {
                response = partyManagementServiceBlockingStub
                        .allocateParty(PartyManagementServiceOuterClass.AllocatePartyRequest.newBuilder().setDisplayName(party).build());
            }

In our scenario, we assume the displayName is the same as the partyIdHint. We found the following results, where the number of characters is the length of the displayName and partyIdHint (if set).

  • 219 characters with no hint: OK
  • 219 characters with hint: INTERNAL: DAML LF Ledger String is too long
  • 218 characters with hint: OK
  • 256 characters with hint: INTERNAL: DAML LF Party is too long
  • 256 characters with no hint: OK
  • 255 characters with hint: INTERNAL: DAML LF Ledger String is too long
  • 255 characters with no hint: OK

We realised that when we did not provide a partyIdHint, it the party name defaulted to some arbitrary name which didn’t surpass the 255 character limit. However, the displayName did not seem to have any limit from what we could tell.

I guess the key thing is that there seems to be some internal limit which doesn’t let us hit the 255 character limit due to the DAML LF Ledger String error and was wondering if this is known behavior or if there are any plans to fix it?

3 Likes
2

We do indeed have an internal hard-coded limit of 255 characters for parties. However, I just noticed this is not reported on the documentation, I’ll quickly amend it.

Is there a specific reason why this limit is too strict for your use case?

1 Like
3

Your report made me notice that we were also not handling properly those errors.

Here is a PR with the documentation fix, plus fixing the error to be INVALID_ARGUMENT instead of INTERNAL (and making sure that we don’t cause errors also for shorter strings, as you pointed out in one of the examples).

Looking forward to hearing your motivation for longer party identifiers. :smiley:

3 Likes
5

Oh no special motivation (yet!), just like to break things :smiley:

4 Likes
6

Please continue doing that, we like fixing stuff. :wink:

4 Likes
7

zoraiz_vs_daml

3 Likes