Integrate latest RPC protocol changes
See https://github.com/Azure/azure-functions-language-worker-protobuf/releases/tag/v1.1.0-protofile.
Released 7 minutes ago. Fast on the pickup. What needs to be changed?
We'll need to expose the cookies via the HttpRequest request binding. The rest of the changes should be a no-op for us.
Would this be worth setting up a time to pair-program on?
Would you like to take a crack at this? We'll need to update the protobuf submodule and then build the azure-functions-shared crate with the compile_protobufs feature to regenerate the Rust code.
From there, add new functionality to HttpRequest to expose the cookie support that was added in https://github.com/Azure/azure-functions-language-worker-protobuf/issues/31.
I might have time to pair on this later this week (today is crazy).
I would. I can read up on it. I am being sent to training Tuesday through Thursday, but could could do some evening time or during work hours on Friday.
@t-eckert I've assigned this one to you given your interest.
I can handle updating my fork of the Azure Functions protocol repo so that we have the latest changes from upstream.
You'll need to regenerate the RPC code:
cd azure-functions-shared/protobufs
git fetch
git checkout 7796ba9
cd ..
cargo build --feature compile_protobufs
git add .
You will need protoc installed from Protocol Buffers.
Once the RPC code is generated, the rest of the work is exposing the new cookies interface on HttpRequest and HttpResponse. See Azure/azure-functions-language-worker-protobuf#32 for the changes that need to be exposed from the Rust API. We'll need a http::Cookie wrapper type for the RPC HttpCookie type that exposes the same sort of data.
I started a skeleton file of what you might be looking for: https://github.com/t-eckert/azure-functions-rs/blob/RCP-http-cookies/azure-functions/src/http/cookie.rs
Is there an example similar to what I'm trying to do that I can use to understand how to connect into the RPC from the cookie file?
You can look to HttpRequest and HttpResponse, both of which wrap the underlying RpcHttp type.
Look to the RpcHttpCookie type to figure out what we need to expose.
In this case, since we can set cookies in the response, we'll need to extend the ResponseBuilder interface to allow users to easily add cookies to the response.
The idea is that we hide away the gRPC implementation details from the users in case it changes and it allows us to offer a simpler API.
@t-eckert how's this work proceeding? Let me know if you need any assistance.
@peterhuene, I did some beginning cursory work, but lost the plot. It would be helpful to do a chat and scope out the work. I am on east coast time right now. Just let me know what your schedule looks like.
I'll have some time tomorrow around noon PST if that works for you. If not, hit me up on Teams and hopefully I'll be free.
Marking blocked on #346.
I think post-hackathon I have a better grasp on what needs to be done for this. We can confab on it this week.
I'd like to get #346 fixed first as I think that would make it easier to implement this change.
For #346, I think we should basically pull the data out from the binding data and into the HttpRequest directly, removing the getter methods.
For HttpResponse, we should stop wrapping a rpc::Http and store the data directly on HttpResponse. Only when we convert to rpc::TypedData would it populate a rpc::Http.
I'm doing this as part of #346.