Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customise the trustedCall response mode #1922

Open
Kailai-Wang opened this issue Jul 22, 2023 · 3 comments
Open

Customise the trustedCall response mode #1922

Kailai-Wang opened this issue Jul 22, 2023 · 3 comments
Labels
D1-feature A new feature, a piece of functionality that needs to be developed I2-medium should be completed within 10 working days

Comments

@Kailai-Wang
Copy link
Collaborator

Kailai-Wang commented Jul 22, 2023

Context

A follow-up issue of #1883
Now that we start to support both synchronous and asynchronous responses, we might want to discuss and decide which mode to use in practice.

There're a few options:

  1. Try to detect it (e.g. by signer) and automatically select the mode
  2. Always send both and it's up to the client which one to use => current implementation
  3. Have a per-trustedCall configuration and follow it in the runtime, e.g.
    • set_user_shielding_key => DI response via ws
    • link_identity => II response via parachain
    • request-vc => both DI and II responses

cc @jonalvarezz @kaylawangnow


✔️ Please set appropriate labels and assignees if applicable.

@Kailai-Wang Kailai-Wang added I2-medium should be completed within 10 working days D1-feature A new feature, a piece of functionality that needs to be developed labels Jul 22, 2023
@kziemianek
Copy link
Member

The StfExecutor already knows which calls are submitted directly/indirectly so with this information we can conditionally send II/DI responses.

It means:

  • for indirect invocations the node will send extrinsics back to parachain signaling processing result
  • for direct invocations the node will send rpc responses back to client, but will not send extrinsics back to parachain
  • if there is any state synchronization needed (for example after VC generation) it will be performed as it is

I can tackle it once #1957 is merged.

@Kailai-Wang
Copy link
Collaborator Author

for direct invocations the node will send rpc responses back to client, but will not send extrinsics back to parachain

Hold on about this one - for some request we might want both, or at least it will have both synchronous responses and parachain effects

@kziemianek
Copy link
Member

@Kailai-Wang which case do you mean ? Isn't it covered by third dot (case vc_issued ) ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D1-feature A new feature, a piece of functionality that needs to be developed I2-medium should be completed within 10 working days
Projects
None yet
Development

No branches or pull requests

2 participants