Question on Stream tracking?

[brummer-simon]

Hi,

In my current job, I need to implement a custom filter transcoding gRPC requests to HTTP1/JSON requests and HTTP1/JSON responses back to gRPC. I implemented basically a mix of the "gRPC HTTP1 reverse bridge" filter and the "json transcoder" filter. For my purposes simple request - response communication patterns are enough.

My test setup uses a downstream client sending gRPC requests to localhost:50051, envoy transcodes them and sends the result to the upstream server on localhost:9999. The server responds with a HTTP1/JSON message, envoy transcodes the result back into gRPC and forwards it downstream to the client. So far all of this works flawlessly.

Now the issue starts: As soon as I send requests concurrently (two threads, each sends only one request over a dedicated gRPC channel), I see that my filter processes both requests as intended, sends them upstream to the server and receives responses.

As soon as encodeHeaders() / encodeData() is called the issues start. From the logs, I see that the associated sessonId of the response associated with the first request, is the sessionId of the second request. As soon as I try to add trailers, a assertion triggers (no Issue in non-concurrent request sending).

The assertion protects addEncodedTrailers(). From the documentation in know that this method is only safe to call by the end of a stream. In my case the end_stream flag claims that this is the case.

So my question is:

• How does envoy track its sessions and what is required that upstream responses are associated with a initial request. Other filters doing similar things and I don't see any traces to handle these things by filter implementors.

To help with answering my question, I've attached the last log from my test run. In line '463': The transcoded request with payload (counter: 99553) has streamId: 4318884623981133489. The received response on the other hand has streamId: 5440753573147363656 (the same as the second request). Since my test reflects the initially sent payload, line 541 shows that it is actually the response to the initial request with a different stream (counter: 99553).

envoy.log

[yanavlasov]

You may ask on Slack #envoy-dev channel to get more help.

[brummer-simon]

Hi @yanavlasov,

I don't have access to Slack. Is there any other way to ask for help understanding the envoy internals?

Cheers Simon

[yanavlasov]

Here is info on how to join Slack https://github.com/envoyproxy/envoy?tab=readme-ov-file#contact

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.