Question about managing state across multiple phases calls in ext-proc for a HTTP request lifecycle

[xr]

Hi, It seems like ext-proc will call the process over gRPC with multiple stages as soon as it can. In case I need to maintain some state per HTTP request on the external server, I'm curious if there's anything we could leverage in ext-proc.

In the WASM filter, each httpContext corresponds to a single HTTP request lifecycle (request/response), meaning the application does not need to manage its own state. I'm wondering if there's a similar mechanism in ext-proc.

For example, how can we check whether an incoming onResponseHeaders is part of the same HTTP request stream as a previous onRequestHeaders call without maintaining the state ourselves?

Some custom solutions I could come up with:

1. Whenever I receive ProcessingRequest_RequestHeaders, generate a unique contextId or leverage the envoy requestId attribute.
2. Keep the state based on the contextId in our own logic.
3. Whenever I receive ProcessingRequest_ResponseHeaders, use the contextId to retrieve the proper state.

It would be great if we have a way to abstract away the above custom logic for maintaining the state, or it might be better to keep the logic externally from envoy, appreciate any insight!

[yanavlasov]

Adding @tyxia @yanjunxiang-google for comments.

[yanjunxiang-google]

HI, @xr
One way I can think of is to have the ext_proc server to track the gRPC stream open/close events, as Envoy starts a new gRPC stream to communicate with ext_proc server for each HTTP stream.

[tyxia]

@xr No additional work is required from ext_proc filter side as such an affinity model has already been maintained in ext_proc's gRPC callout.

This can be purely your external server logic: On the first event (e.g., request header), server has a unique ID per stream and maintain it throughout HTTP lifecycle (request/response).
We actually have an internal product that is doing something similar. And it has been working well.

[xr]

@yanjunxiang-google @tyxia thanks for the info! good to hear that you are doing sth similar, if each http stream is corresponding with one grpcStream then I could also store the http state inside grpc stream.