Hi all, I clone the da-marketplace-0.1.15 sample app from Github and compile it without any error. However, when I declare dependencies from SDK 1.7.0 to SDK 1.10.0 in daml.yaml and package.json of the ui, I got this error:
TypeScript error in /Users/alexho/da-marketplace-0.1.15/ui/src/components/Broker/BrokerOrders.tsx(164,36):
Argument of type ‘Choice<BrokerOrder, BrokerOrder_Fill, ContractId, Tuple2<string, string>>’ is not assignable to parameter of type ‘Choice<BrokerOrder, { depositCid: string; }, ContractId, DamlTuple>’.
The types of ‘template().keyEncode’ are incompatible between these types.
Type ‘(k: Tuple2<string, string>) => unknown’ is not assignable to type ‘(k: DamlTuple) => unknown’. TS2345
The above errors show up only when I update these 3 libraries and daml.yaml to 1.10.0. If I only update sdk version in daml.yaml to 1.10.0 and still maintain 1.7.0 for the package.json, there is no error.
I was able to reproduce. It looks like a regression to me. I’ve opened ticket #9046 to track this. It also contains a workaround, which involves manually casting depositCid, which is a string to a ContractId.
Edit: @Alex have a look at the discussion in the linked ticket. This was a bug in 1.7.0 rather than a regression in 1.10.0, as you were able to pass completely illegal types in for args.
If you want real type-safety, I’d fix this by changing the type of your state variable:
There is also another branch at GitHub - digital-asset/da-marketplace at sales-eng that is already on SDK 1.10.0. It has diverged a bit from master but should hopefully be merged back into master within the next few weeks.
Thank you @bernhard and @cocreature. I did the “as” cast and rebuilt, but got another compiling error shown below. It seems the master branch needs to fix a number of issues before it can move on to 1.10.0. For now I’ll use it as it is and wait for new release because I’m new to DAML, need to know more than a few things to get it work.
Do you know which branch the DA Marketplace sample app on project:DABL is using? it is working like a charm. However, if I compile the master branch (for 1.7.0 because it has no error) and replace the sample app’s ui module by my compiled ui module, it stops working.
TypeScript error in /Users/alexho/da-marketplace-0.1.15/ui/src/components/common/Holdings.tsx(249,44):
Argument of type ‘Choice<Investor, Investor_AllocateToProvider, ContractId, Tuple2<string, string>>’ is not assignable to parameter of type ‘Choice<Investor, { depositCids: string; amount: string; provider: string; }, ContractId, DamlTuple>’.
Types of property ‘template’ are incompatible.
Type ‘() => Template<Investor, Tuple2<string, string>, string>’ is not assignable to type ‘() => Template<Investor, DamlTuple, string>’. TS2345
247 | switch(role) {
248 | case MarketRole.InvestorRole:
As for the other issue, ideally push it as far up as possible and do the conversion to ContractId<AssetDeposit> at the edges but you can also do the local as cast here.
I would have thought that it runs from master but I’ll check and get back to you. As for your issue with “it stops working” is that the typescript error you shown below or something else? I’m a bit confused why you get a typescript error if you replace it with your compiled ui module.
As for your issue with “it stops working” is that the typescript error you shown below or something else? I’m a bit confused why you get a typescript error if you replace it with your compiled ui module.
@cocreature, the typescript errors only occur when I compile it using sdk version 1.10.0. It has no error at all and compile successfully if I use 1.7.0. The reason I replace the sample app’s UI with my compiled UI because I want to change the UI to suit my need.
Sorry that I made you confused when I said “it stops working”. What I meant is when I open the app, the loading page keep saying “Loading…” and hangs there, not even open the login page. If I use the default sample app UI, everything is just working fine.
Just to clarify, when I compiled the source code cloned from Github, I didn’t make any change. I just compile and upload to project:DABL to see whether it works. But it ended up not working. Thanks.
I was able to reproduce the problem and found, in this case, the issue is caused by stale DARs that were built with a different Daml version. This results in mismatched template IDs between the DAR deployed from the Sample Apps, and the UI you built from master.
To fix, run rm -rf .daml/ and build the UI again. (We are adding this step to our Makefile, so that it is included in the make clean target)
Generally to avoid this sort of issue as you develop and start introducing your own changes, the recommended approach is to build the entire app with make package and deploy the DIT build artifact (found in target/da-marketplace-VERSION-.dit to a fresh ledger
EDIT: To also add to the above, there is a local dev story to speed up the feedback loop, so you don’t always have to build and deploy to Daml Hub for testing smaller changes - instructions are located in our README here
thanks a lot @Alex_Matson. When I build the entire app and deploy the DIT file as you advised, I couldn’t get the Exberry adapter work. Here is the logs:
{“kind”:“Status”,“apiVersion”:“v1”,“metadata”:{},“status”:“Failure”,“message”:“container "bot" in pod "pythonbot-zchkzmhidlg5t4sf" is waiting to start: PodInitializing”,“reason”:“BadRequest”,“code”:400}
— End of log stream
Even after a day, it still shows the above text. Again, I used the cloned Github da-marketplace repo without any amendment.
When I deploy the DA Marketplace sample app, the Exberry adapter seems working. After I deployed the adapter for a while, the log showed as below. Could you please help me double-check this issue? The compilation of the Exberry adaptor bot didn’t show any error, but seems that it is not working properly. I needs to work with Exberry matching engine, so really need to get the adapter work. Thanks.
We just updated the master branch of da-marketplace to use the SDK version 1.10 and switched to a different method of building the Exberry adapter. Hopefully this fixes these issues for you!
Note that the new build method requires pipenv which can be installed using brew or pip. When building the adapter for the first time, it may ask you for permission to install a different version of python. If so, you can say yes - it will install it locally for the virtual environment and should not change your system’s default python configuration.