Skip to content

Propagation changes in anticipation of W3C support#12

Merged
dgoffredo merged 11 commits intomainfrom
david.goffredo/w3c-propagation-preparation
Dec 19, 2022
Merged

Propagation changes in anticipation of W3C support#12
dgoffredo merged 11 commits intomainfrom
david.goffredo/w3c-propagation-preparation

Conversation

@dgoffredo
Copy link
Copy Markdown
Contributor

I'm reading through our internal RFC about adding support for W3C-style trace context propagation.

This pull request has changes in anticipation of that feature.

Copy link
Copy Markdown
Contributor

@cgilmour cgilmour left a comment

Choose a reason for hiding this comment

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

A few comments for now


// Parse the propagation styles from the configuration and/or from the
// environment.
// Exceptions make this section simpler.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

How would it look with error-handling instead of exceptions?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It would be a lot longer.

// environment.
// Exceptions make this section simpler.
try {
const auto global_styles = styles_from_env(env::DD_TRACE_PROPAGATION_STYLE);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

By this point, I'm wondering the value here of the macro aligning variable names with environment variable names.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The benefit is that there's one way to add an environment variable: by adding an enum value. The list of environment variables consumed by nginx is then automatically up-to-date.

if (!result.extraction_styles.datadog && !result.extraction_styles.b3 &&
!result.extraction_styles.none) {
return Error{Error::MISSING_SPAN_EXTRACTION_STYLE,
"At least one extraction style must be specified."};
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could we just fall back to a default in this instance, ie: datadog extraction / injection.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

True. The thing is, the only way to get this error is if the user explicitly said "the list of styles is empty."

If empty is a suitable default, then why have an explicit "none" style, especially if "none" only makes sense by itself? Better to just have "no styles" mean "no propagation."

Alas, "none" is in our spec.

Since the easiest way to get the default behavior is to not configure the styles, I'd rather have this error than add another way to get the default behavior.

@dgoffredo
Copy link
Copy Markdown
Contributor Author

Thanks for the review. I'll continue adding to this PR today.

@dgoffredo dgoffredo merged commit d8157f2 into main Dec 19, 2022
@dgoffredo dgoffredo deleted the david.goffredo/w3c-propagation-preparation branch December 19, 2022 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants