-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat(proxy-wasm) foreign function support #626
base: main
Are you sure you want to change the base?
Conversation
d4b4267
to
99b8e75
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #626 +/- ##
===================================================
- Coverage 90.84288% 90.73090% -0.11198%
===================================================
Files 52 53 +1
Lines 11259 11479 +220
===================================================
+ Hits 10228 10415 +187
- Misses 1031 1064 +33
... and 2 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more. |
99b8e75
to
5bb49f5
Compare
08ec198
to
2ecb389
Compare
b4d763b
to
370b775
Compare
370b775
to
20d5be4
Compare
Making struct member names explict to distinguish them from the upcoming Proxy-Wasm foreign call support.
20d5be4
to
9910a5b
Compare
b661016
to
0d11869
Compare
Codecov is playing games with me. It's reporting lines that are definitely covered by tests as uncovered. |
90edd6e
to
b8d786f
Compare
t/03-proxy_wasm/hfuncs/contexts/140-proxy_foreign_function_resolve_lua.t
Outdated
Show resolved
Hide resolved
t/03-proxy_wasm/hfuncs/contexts/140-proxy_foreign_function_resolve_lua.t
Show resolved
Hide resolved
[error] | ||
can only call resolve_lua during "on_request_headers", "on_request_body", "on_dispatch_response", "on_tick", "on_foreign_function" | ||
--- no_error_log | ||
[crit] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, we would have to also add a new test case to all context checks for the new on_foreign_call
step... I was going to say we can factorize both those steps together (since they both are "background calls"), but we may want some functions to be disabled in one but not the other...
This makes me think of some cases that we ought to test, for example making a dispatch call during on_foreign_call
and vice-versa... This test is also relevant as we factorize both call queues. Maybe we ought to add the new step to the context tests...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, as I was implementing support for calling lua_resolver
from on_http_call_response
I noticed that the code also allowed for calling dispatch_http_call
from on_foreign_call
and that on_foreign_call
would be an additional check in the context tests for the hostcalls.
There's a test asserting that filter developers can call the lua_resolver
from the on_http_call_response
callback; but tests not strictly related to the lua_resolver
function (e.g. calling http_call
from on_foreign_call
and the new on_foreign_call
check in the context checks) were left to be addressed in a separate PR as this one is already rather large.
I can include them in this PR. though; if you prefer that way.
I agree that there's value in keeping them separate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests not strictly related to the lua_resolver function (e.g. calling http_call from on_foreign_call and the new on_foreign_call check in the context checks) were left to be addressed in a separate PR as this one is already rather large.
Let's add them in this PR, they belong to this feature and that way it will be done. The PR is not very large to me, it's alright.
@@ -8,7 +8,8 @@ edition = "2018" | |||
crate-type = ["cdylib"] | |||
|
|||
[dependencies] | |||
proxy-wasm = "0.2" | |||
#proxy-wasm = "0.2" | |||
proxy-wasm = { git = "https://github.com/casimiro/proxy-wasm-rust-sdk.git", branch = "foreign-function-callback" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmm, this may be a blocker until it is merged upstream... Actually, getting the feature merged upstream may be a requirement for merging this PR, don't you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was hoping the changes in the upstream would be merged by the end of this PR.
On one hand, this workaround seems very subpar and makes me want to consider it a blocker.
On the other, that separate branch contains a single commit that's already been approved by the maintainers and should be part of the next release; and using this separate branch would allow us to ship foreign function support in time for the 3.9 release of the gateway.
87e0f67
to
7eb64b5
Compare
…aration Handles the case when the expression defining a variable being declared is a function call receiving arguments that don't fit in the same line, e.g.: ngx_proxy_wasm_exec_t *pwexec = ngx_proxy_wasm_instance2pwexec( instance);
The trap message describing the lua_resolver being called in unsupported context exceeds the current limit.
7eb64b5
to
d217d1a
Compare
Foreign Function Support
The Proxy-Wasm spec defines the function
proxy_call_foreign_function
and the callbackproxy_on_foreign_function
that filter developers can use to invoke host specific functions, a.k.a. foreign functions, and receive callbacks.A foreign function invoked with
proxy_call_foreign_function
may return its value immediately -- as part of the returned value of theproxy_call_foreign_function
call; or it can return it later, writing it to theFOREIGN_FUNCTION_ARGUMENTS
buffer, and invokingproxy_on_foreign_function
with an id identifying the function initially called.This PR adds support for the mechanism described above; and although the spec doesn't restrict when foreign functions can be called, in
ngx_wasm_module
they cannot be invoked fromproxy_on_configure
orproxy_on_vm_start
.DNS resolution
This PR also exposes the Lua DNS resolver through the
resolve_lua
foreign function.This function expects the name to be resolved as its single argument. If the name can be resolved without performing any IO, the resolved address is put in the returned value of
proxy_call_foreign_function
.If the resolver needs to forward the resolution request to a DNS server, the resolved address and the name itself are written to the
FOREIGN_FUNCTION_ARGUMENTS
buffer and theproxy_on_foreign_function
callback is invoked withfunction_id
0, as soon as the address is returned from the server.TODO
on_tick
support