Daml hub quirks

Hello everyone,

While attempting some tests on the daml hub platform I encountered a couple of issues I wanted to address here:

  • Firtsly, while creating a contract, in which one of the fields is a list of a custom data type, if no element is added to said list, the fields wasn’t passed on to the request at all and I received an error with the following output:
JsonError: spray.json.DeserializationException: Can't read { ... } as DamlLfRecord Foo, missing field 'field'
  • The second issue was that sometimes, when creating contracts/exercising choices, updating fields on the UI wasn’t being reflected on the payload of the request going through.

  • Finally, whevener I tried using the search bar feature to look up a template Id or contract Id, I would get redirected to the following page.

Thank you in advance.

1 Like

Thank you very much for reporting! We’ll look into these issues and fix them ASAP!

Thanks

Hi, is there an estimate upon which the topics raised are fixed, or are they fixed already?

Regards

Luis,

The issues raised have been logged internally, however they have not all been fixed. I will personally take responsibility for these in the next few days.

Apologies for the delay,

Sarah

2 Likes

Thank you @sarah.breckenridge :+1:

Luis,

Fixes for the above issues have been committed to our repo and will go live in the console at the time of our next production release.

If the second issue you described happens again, feel free to ping this thread with details as to what changes are not being reflected in the payload of your request. That way I can take care of any remaining issues you may be experiencing.

Thank you for your patience with these fixes and have a nice weekend,

Sarah

1 Like

Thank you @sarah.breckenridge,

As a final remark, could you specify the currently expected schedule to release these fixes into production?
We’ve noticed somewhat of a pattern in the announcements which seemed to indicate a monthly release (Announcements - Daml Developers Community). Can we expect a release in the next few days given this?

Would it also be possible/feasible to have an available schedule of expected releases into Daml Hub at an earlier stage?

Regards,
Luís

Luis,

After speaking with our project manager, we will work on a published update schedule which should give a longer view soon. Otherwise, the quirks pointed out at the origin of this thread have been solved for and are in our production environment.

Thanks, and let me know if I can help with anything else -

Sarah

1 Like

Hey Luis,

As Sarah says, we’ll work on publishing a longer looking release and update schedule soon.

Thanks, David.

1 Like

Hi,

This issue seems to not have been fully fixed.
Please find below an example of a complex data type with a similar structure to where we tested out these situations.

​​{"contractId":"0066813c669bcd3f335cb66f8b5c4676eae93b8e3ada6ba0f31dbd88f79c9b6f2",
 "templateId":"9123f8816d176d425bd932c95fb87fbac61def6fb26fb2e3d1cdcbda2de7add7:Module.Event:",
 "choice":"Request",
 "argument":{
   "Origin":{
     "tag":"Event","value":{
       "Results":[],
       "Label":"Event",
       "description":"Event description",
       "market":{
         "tag":"Sport",
         "value":"Soccer"},
       "sub":[{
           "tag":"Country",
           "value":"USA"}],
       "Title":"XvsY",
       "eventParticipants":[{
         "op":[""],"name":"X","id":"3","order":"1"},{        <- op and id did not update correctly upon change
         "op":[],"name":"Y","id":"2222","order":"2"}],
       "Date":"2022-05 16T23:00:00.000Z",
       "Status":"Active",
       "Payload":"qwerty", <- tried to change from value presented to "{}" and didn't change on request
       "outcomes":[{
         "outcome":{
           "participantId":"33",
           "type_":"TwoWay",
           "subtype":"Win"},
           "odd":{"tag":"Decimal","value":"2.0"}},
         {"outcome":{  
           "participantId":"2222",
           "type_":"TwoWay",
           "subtype":"Draw"},
           "odd":{
             "tag":"Decimal",
             "value":"10.0"}}]}}}}

What we’re witnessing is that, when updating the various inputs required on the UI, the changes done don’t match what gets sent out to the HTTP JSON API.

Examples:

  • Select boxes do not correctly update the value - option is changed and is not reflected on the request
  • Text fields do not update the full string - where on the UI it shows “3333” it got translated into the request as “33” or sometimes even just “3”
  • No item was added to a list and the request that got sent had an item in it
  • Added item to a list and then removed and it was still sent on the request

Luis,

Thanks for sending the data type - that is super helpful. If you are able to send the .dar or daml contract for which you are seeing these issues, that would also be helpful!

A few follow up questions:

  • for the select box case, is this when an optional input is rendered? What kind of select box?
  • for the text fields, does this happen every time? Or only when the text is nested in another type?
  • for the empty list, what item does the list get sent with? An empty string?

Thanks for your patience and help with this!

Sarah