Wrong parameter formatting in wasp-cli output of failed request

[Juliusan]

Reproducing the error: Create a chain and post an incounter (or possibly any contract) request without deploying the contract to the chain. This is the output from wasp-cli while checking the result of the request:

$ ./wasp-cli chain request 0x9ba17bcf98a9a3d9a9097e9bb07ff252b914f0d63b12a794ce74d2d9dd787cff0000
Request found in block 2

Request 0x9ba17bcf98a9a3d9a9097e9bb07ff252b914f0d63b12a794ce74d2d9dd787cff0000:
  Kind: on-ledger
  Sender: tst1qrvul02j8wzrm2mw83c6nfvhu66r30ee4vvx9x064gnlufwwe652c6jlxle
  Contract Hname: af2438e9
  Entry point: d351bd12
  Arguments: (empty)
  Error: contract not found id:%!d(float64=2.938386665e+09)

Total 0 events

The Error part is obviously incorrectly formatted. Contract ID is supposed to be int32 instead of float64. In fact, it is logged correctly in wasp log:

 2023-01-18T07:20:53Z   DEBUG   Chains.0x22a27ff6.C-0x91e265e0.LI-3.VM  writeReceiptToBlockLog: 0x9ba17bcf98a9a3d9a9097e9bb07ff252b914f0d63b12a794ce74d2d9dd787cff0000 err: contract not found id:2938386665

So I suspect, the type is lost somewhere in marshalling/unmarshalling of error parameter, but I didn't have any luck in finding the exact reason. Maybe someone else will.

[dessaya]

I think this is a consequence of using JSON for marshalling the error parameters, since any integer is unmarshalled as a float :man_facepalming:

[lmoe]

See: https://github.com/iotaledger/wasp/issues/1641

I've "fixed" it for now, by forcing ErrContractNotFound to be formatted as an int. But this only works on Wasps side, not in the CLI I fear. But yeah, this is suboptimal.