Conversation
lpahlavi
force-pushed
the
lpahlavi/defi-2643-proxy-runtime
branch
2 times, most recently
from
adbcc5d to
2365ffa
Compare
lpahlavi
force-pushed
the
lpahlavi/defi-2643-proxy-runtime
branch
from
2365ffa to
3e3db6d
Compare
lpahlavi
force-pushed
the
lpahlavi/defi-2643-proxy-runtime
branch
from
3e3db6d to
50dee58
Compare
| In: ArgumentEncoder + Send, | ||
| Out: CandidType + DeserializeOwned, | ||
| { | ||
| self.runtime.query_call(id, method, args).await |
There was a problem hiding this comment.
Shouldn't query call also go through the proxy? E.g. Some query endpoints on the target canister could be restricted to a controller (which would be the proxy)
There was a problem hiding this comment.
Good question, and yes I agree that this is not quite optimal but the problem is that the proxy canister only has one proxy endpoint which is an update endpoint.
To be very honest though, I'm not actually 100% certain how the ic-cdk differentiates between update and query calls with the new API since both types of calls are made with Call::bounded_wait or Call::unbounded_wait anyways...
There was a problem hiding this comment.
but the problem is that the proxy canister only has one proxy endpoint which is an update endpoint.
right I forgot that query endpoint cannot trigger inter-canister calls, so that doesn't make sense (should also answer your question about Call)
|
|
||
| #[async_trait] | ||
| impl<R: Runtime + Send + Sync> Runtime for ProxyRuntime<R> { | ||
| async fn update_call<In, Out>( |
There was a problem hiding this comment.
We should probably have at least one smoke integration test (with the proxy canister wasm) to ensure that it works as expected.
There was a problem hiding this comment.
Good idea, I will add one!
|
@gregorydemay I've added some simple integration tests for the new |
2 participants
Add a
ProxyRuntimethat wraps anotherRuntimeinstance and forwards update calls through the provided proxy canister.