Issue when using `Tendermint*` properties for url or body parameters in a webhook

[lietho]

baseledger_api_proposal_v0.5.md mentions that is possible to use TendermintBlockId, TendermintTransactionId and TendermintTransactionTimestamp in the url or body params of a SOR webhook. Unfortunately this doesn't work because of several reasons:

• TendermintTransactionTimestamp is of type sql.NullTime. The way the URL or the body of the request are created (buildWebhookRequestBody and buildWebhookRequestUrl in system_of_record_hook.go) results in a string similar to "{2022-05-28T05:41:13Z true}". It would be better to just have the time in the string.
• At the time the webhook request URL and body are build, the mentioned properties are not yet set on the trustmesh entry. The trustmesh entry gets created without these properties set. In ExecuteBusinessLogic the webhook will be triggered first and at the end setTxStatus is called to update these properties.

I have created an ugly workaround for myself to overcome this issue, but I don't want to share it with the public :-) Maybe it is possible to update the properties already before triggering the webhook?

[skosito]

Thanks for submitting the issue, great catch.

• I think you are right here, even though this is not a bug, recipient of this request can just parse it, or this is a bug? We can improve this on proxy side ofc.
• I think there are 2 possible ways to tackle this, but further checks are needed to verify which one is better and if there are some side effects. Either we setTxStatus first and then proceed with the rest of business logic, or we can use txResult that is available in ExecuteBusinessLogic to add these fields to trustmeshEntry before hook request body is built. Does this make sense, is this similar to your workaround?

These 2 issues can be solved in 2 separate PRs, not sure when we will be able to pick them up, but they are good first issues for open source contributions if somebody is available.

[lietho]

You are right, the recipient could parse the value. But this requires additional work, whereas just using the ISO 8601 date value should work out-of-the-box with most JSON parsers. I just don't know, what's the best way to fix this. In my workaround I have hard-coded a check if the param.ParamValueField is "TendermintTransactionTimestamp". Maybe there is a better solution.

In my opinion the easiest fix for the second problem would be to call setTxStatus right before the switch trustmeshEntry.EntryType. txResult isn't used somewhere inside the switch so it should be a safe change.

[skosito]

For first one parsing should be on proxy side when payload is created and recipient would either get timestamp string or null, as opposed to getting object, does this make sense?