[System.Diagnostics.DiagnosticSource.Activity] Reset recorded flag when creating activity when not requested by sampler(s)

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh

[CodeBlanch]

Changes

• Reset ActivityTraceFlags.Recorded when creating activity if not requested by sampler(s) because it may be inherited from a parent

Details

[Ran into this while working on #6058.]

Scenario:

• We have an incoming request with traceparent marked as Recorded.
• OTel sampler decides to drop for whatever reason.
• Because this is a root, even though a drop was requested, OTel SDK will still create a propagation-only span/activity.
• Here is the issue: The created span/activity inherits recorded from the parent context and therefore has Recorded=true. A propagation-only span should have Recorded=false.

/cc @tarekgh@noahfalk@samsp-msft@cijothomas@alanwest

[tarekgh]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

---

Refers to: src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs:1236 in 5d2e54d. [](commit_id = 5d2e54d, deletion_comment = False)

[tarekgh]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

[CodeBlanch]

 activity.ActivityTraceFlags = parentContext.TraceFlags;

should the fix done here instead?

@tarekgh I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

[CodeBlanch]

@CodeBlanch how likely this change can break anyone depending on the current behavior? I am asking to know if we need to file a breaking change for that.

Kind of hard to say.

Here are some thoughts...

The default sampler in OTel is ParentBased(AlwaysOn) which means first check the parent. If the parent is marked as Recorded (aka sampled) then respect that and create a recorded child. If there is no parent, create a recorded/sampled span (AlwaysOn).

So no one using the defaults will be impacted.

To be impacted users would have to switch the sampler or make a custom one which attempts to drop remote things. The bug is such that the drop isn't really respected. Recorded causes the spans to be exported (but they have IsAllDataRequested=false so they won't be populated). Impact is probably higher costs, maybe some screwy spans without data. What may be more interesting is that span, if it is propagated out of proc, will be transmitted as Recorded. So some other system downstream using ParentBased might decide to sample it fully essentially reversing the drop decision.

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

[tarekgh]

I thought about just removing that line. That would probably take care of it. The reason I went with the explicit clear is because right now ActivityTraceFlags only has the Recorded definition. But who knows in the future it may have other flags which actually should inherit from the parent. Kind of hard to predict 😄 Happy to this though just LMK.

We don't have to remove the line if we are worried about the future adding to the flags. But we can just modify it to the following:

activity.ActivityTraceFlags=parentContext.TraceFlags&~ActivityTraceFlags.Recorded;

[tarekgh]

FWIW if this was being done in OTel SDK we would probably call it a breaking change to align behavior with spec.

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

[tarekgh]

Thanks @CodeBlanch

[noahfalk]

That makes me feel we need to file a breaking change to get this documented. @noahfalk may weigh on that too. Here is where you can file the breaking change https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml.

Yeah, I think a breaking change notice would be warranted here. For downlevel what is the plan? Just warn users that they won't be able to disable the recorded flag?

[tarekgh]

@CodeBlanch could you please file the breaking change in https://github.com/dotnet/docs/issues/new?template=02-breaking-change.yml? Thanks!

[CodeBlanch]

@tarekgh Done, see link above ^

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[tarekgh]

/ba-g the failure is known build timeout issue happening in other PRs too.

[alanwest]

Why does this line exist at all? If W3C trace context introduces new flags, what is to say that inheriting the flags from the parent will be the correct thing to do for those new flags?

[alanwest]

Ah, I see this was already discussed... removing the line seems more correct to me...

[alanwest]

In looking at the latest editor's draft of the spec, there is a new flag proposed: Random Trace ID Flag. My read of this flag is that it actually should be inherited from the parent, but there's no way to be certain this will be true for all new flags.

[tarekgh]

Keeping this line is not hurting for now. Any newly introduced flag will need to be decided if it is inheritable from the parent or not anyway.

[ericstj]

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2025-10-03 13:49:29

[tarekgh]

@ericstj the breaking change for this is already submitted and finalized dotnet/docs#44282.

[ericstj]

Thank you @tarekgh