build_assertion error doesn't propagate to parachain

[Kailai-Wang]

Context

Repro-case:

• set user shielding key for "//Bob"
• request vc (e.g. A1) for "//Alice"

In tee-worker I see:

[2023-03-02T09:29:30Z DEBUG ita_stf::trusted_call_litentry] who "d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d", assertion A1
[2023-03-02T09:29:30Z ERROR ita_stf::trusted_call_litentry] user shielding key is missing, "d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d", A1
[2023-03-02T09:29:30Z ERROR itp_stf_executor::executor] Stf execute failed: AssertionBuildFail

which is good.
However, such error never arrives in parachain.

When I check the code, we never properly handle the errors:
https://github.com/litentry/litentry-parachain/blob/19951d385f70f3cb676653e22008638c4abdc234/tee-worker/app-libs/stf/src/trusted_call.rs#L601

Please also have ts-tests for this

---

✔️ Please set appropriate labels and assignees if applicable.

[Kailai-Wang]

related: #1252

[0xverin]

There should be add some new case,at least show fail reason in the StfError event:

1. dsiableVc that don't requestVc before or dsiableVc with wrong index(only user shielding key is missing in worker log)；
2. revokeVc width error index(nothing in log)
3. dsiableVc index that has been dsiableVc(nothing in log)

cc @zhouhuitian

[outofxxx]

In on_success function should return error too.

https://github.com/litentry/litentry-parachain/blob/7f33bd9aed424002d3af8a6dce17c4d9019a1137/tee-worker/litentry/core/stf-task/receiver/src/handler/assertion.rs#L195-L211

[jingleizhang]

This case is handled, when: 1. set user shielding key for "//Bob", 2. request vc (e.g. A1) for "//Alice".

Although the returned reason is lacking detailed information.

[outofxxx]

When AssertionBuildFail is occurring, We could

1. emit error!() log
2. propagate more details to parachain, likes

Err(StfError::AssertionBuildFail("User shielding key is missing"))

@jingleizhang

[outofxxx]

There should be add some new case,at least show fail reason in the StfError event:

1. dsiableVc that don't requestVc before or dsiableVc with wrong index(only user shielding key is missing in worker log)；
2. revokeVc width error index(nothing in log)
3. dsiableVc index that has been dsiableVc(nothing in log)

cc @zhouhuitian

1. disable a non-exists vc or with a wrong index, we will emit VCNotExist { index }.
2. the same to revoke_vc, will emit VCNotExist { index }.
3. I think 3 is the same as 1
   Is that ok to send VCNotExist { index } event to FrontEnd?

@Verin1005