Skip to content

Conversation

@e-n-0
Copy link
Member

@e-n-0 e-n-0 commented Aug 8, 2025

What does this PR do?

This PR refactor how the envoy contrib is handling messages. Now the processing of analysis messages (request headers, request body, response headers, response body) is now implemented agnostic to the framework its instrumenting. This is implemented in the package message_processor.

Motivation

The motivation to create a new package message_processor is the ability to re-use the message processing logic as an external processor. This package will be used in part of #3912 that implement the support of messages processing for HAProxy.

The package message_processor is implemented inside the envoy contrib to keep the agility of deploying releases out of the normal releases process of the tracer (using the -docker.x tag).

Reviewer's Checklist

  • Changed code has unit tests for its functionality at or near 100% coverage.
  • System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
  • There is a benchmark for any new code, or changes to existing code.
  • If this interacts with the agent in a new way, a system test has been added.
  • New code is free of linting errors. You can check this by running ./scripts/lint.sh locally.
  • Add an appropriate team label so this PR gets put in the right place for the release notes.
  • Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.

Unsure? Have a question? Request a review!

@github-actions github-actions bot added the apm:ecosystem contrib/* related feature requests or bugs label Aug 8, 2025
@e-n-0 e-n-0 force-pushed the flavien/envoy/refactor-separation branch from 062d617 to fa1be8a Compare August 8, 2025 15:08
@pr-commenter
Copy link

pr-commenter bot commented Aug 8, 2025

Benchmarks

Benchmark execution time: 2025-08-25 13:41:13

Comparing candidate commit 6db4230 in PR branch flavien/envoy/refactor-separation with baseline commit b5536ad in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 24 metrics, 0 unstable metrics.

@e-n-0 e-n-0 changed the title contrib/envoy: implement a message_processor contrib/envoy: implement a message_processor to reuse logic Aug 8, 2025
@e-n-0 e-n-0 force-pushed the flavien/envoy/refactor-separation branch 2 times, most recently from 048876a to 049d56e Compare August 25, 2025 13:07
@datadog-datadog-prod-us1
Copy link

datadog-datadog-prod-us1 bot commented Aug 25, 2025

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 6db4230 | Docs | Was this helpful? Give us feedback!

@e-n-0 e-n-0 marked this pull request as ready for review August 25, 2025 13:27
@e-n-0 e-n-0 requested a review from a team as a code owner August 25, 2025 13:27
@e-n-0 e-n-0 force-pushed the flavien/envoy/refactor-separation branch from 9483abb to 6db4230 Compare August 25, 2025 13:28
@e-n-0 e-n-0 marked this pull request as draft August 25, 2025 13:39
@e-n-0 e-n-0 changed the title contrib/envoy: implement a message_processor to reuse logic refactor(contrib/envoy): implement message_processor for logic re-use Aug 25, 2025
@e-n-0 e-n-0 marked this pull request as ready for review August 26, 2025 13:13
"sync/atomic"
"time"

"github.com/DataDog/dd-trace-go/contrib/envoyproxy/go-control-plane/v2/message_processor"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually underscores in package names are banned by the geneva convention. Something like msgproc should be enough. Usually I encourage longer names but with package names this create a bunch of wierd issues so no

}

// Handle the action returned by the message processor
processingResponse, err := s.handleAction(action, &processingRequest)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you really need a pointer to the processing request here or a copy would be fine?

Comment on lines 187 to +195
var (
response *envoyextproc.ProcessingResponse
action message_processor.Action
err error
reqState *message_processor.RequestState
)
response, *currentRequest, err = s.messageProcessor.ProcessRequestHeaders(ctx, v)
return response, err
reqState, action, err = s.messageProcessor.OnRequestHeaders(ctx, &requestHeadersEnvoy{v, s.config.Integration})
if err == nil {
*currentRequest = *reqState
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
var (
response *envoyextproc.ProcessingResponse
action message_processor.Action
err error
reqState *message_processor.RequestState
)
response, *currentRequest, err = s.messageProcessor.ProcessRequestHeaders(ctx, v)
return response, err
reqState, action, err = s.messageProcessor.OnRequestHeaders(ctx, &requestHeadersEnvoy{v, s.config.Integration})
if err == nil {
*currentRequest = *reqState
}
var (
action message_processor.Action
err error
)
*currentRequest , action, err = s.messageProcessor.OnRequestHeaders(ctx, &requestHeadersEnvoy{v, s.config.Integration})

Comment on lines +49 to +51
func (a *requestHeadersEnvoy) EndOfStream() bool {
return a.req.RequestHeaders.GetEndOfStream()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This kind of boilerplate can be avoided by using embedding on the right object

Comment on lines +107 to +113
func (a *requestBodyEnvoy) Body() []byte {
return a.req.RequestBody.GetBody()
}

func (a *requestBodyEnvoy) EndOfStream() bool {
return a.req.RequestBody.GetEndOfStream()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here about embedding

headerMutation, err := reqState.PropagationHeaders()
if err != nil {
reqState.Close()
return nil, Action{}, err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for the action{}

if !req.EndOfStream() && mp.isBodySupported(httpReq.Header.Get("Content-Type"), mp.config) {
requestBody = true
reqState.AwaitingRequestBody = true
// Todo: Set telemetry body size (using content-length)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we do it here ?

Comment on lines +75 to +78
if mp.config.BodyParsingSizeLimit <= 0 || !reqState.AwaitingRequestBody {
mp.instr.Logger().Error("message_processor: the body parsing has been wrongly configured. " +
"Please refer to the official documentation for guidance on the proper settings or contact support.")
return newContinueAction(), nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you mean by wrongly configured. I don't see how it could be actionable for a user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am trying to understand why the types and funcs in this file are here if the interfaces from this package are delegating this job

}

if currentRequest.Blocked {
if _, ok := processingResponse.Response.(*envoyextproc.ProcessingResponse_ImmediateResponse); ok {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasn't the ActionType made for this kind of cases ?

@e-n-0
Copy link
Member Author

e-n-0 commented Sep 12, 2025

supersed by #3945

@e-n-0 e-n-0 closed this Sep 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

apm:ecosystem contrib/* related feature requests or bugs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants