-
Notifications
You must be signed in to change notification settings - Fork 123
.NET Framework SqlCommand IL rewrite for SqlClient instrumentation
#4470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 5 commits
bc134fa
9fcab4e
e316036
3f1876d
394e517
8b6c94b
3691cf4
355be86
23ced4c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,11 @@ | |
|
|
||
| ### Added | ||
|
|
||
| - IL rewrite for SqlCommand on .NET Framework to ensure CommandText is available for | ||
|
Check failure on line 12 in CHANGELOG.md
|
||
| [SqlClient instrumentation](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/4343). | ||
| This is enabled by default but can disabled via the | ||
| `OTEL_DOTNET_AUTO_SQLCLIENT_NETFX_ILREWRITE_ENABLED` environment variable. | ||
|
|
||
| ### Changed | ||
|
|
||
| #### Dependency updates | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -50,6 +50,7 @@ bool IsDumpILRewriteEnabled(); | |
| bool IsAzureAppServices(); | ||
| bool IsFailFastEnabled(); | ||
| bool IsNetFxAssemblyRedirectionEnabled(); | ||
| bool IsSqlClientNetFxILRewriteEnabled(); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ideally, it should be propagated from the managed coded. We are in the middle of introducing File based configuration and it need to be reworked in the near feature. Not a blocker for this PR IMO. Ref: #4492 |
||
|
|
||
| } // namespace trace | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some doubts here. As t might impact end-users, I would consider this as opt-in feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am actually leaning towards on by default because the effect is that the user gets one more attribute on their spans, so overall this improves the tracing quality automatically and makes it more appealing to use our automatic package. If there are any side-effects from turning this on, then we should promptly identify and resolve them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, I think that the side-effects that I'm most concerned about are outside of our control. The code that we are modifying causes the sql to get written to an EventSource. When things are written to an EventSource, that data can now be consumed by other things, including things that can result in data getting persisted outside of the process. Those things may not be sanitizing the sql, or may assume that the data was safe to begin with (just the stored procedure).
I think having it on would be fine for the majority of users, but there are probably a few that would run into problems with having this data present by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I overlooked the fact that we're writing to an EventSource and not directly updating the span. It makes sense then to have users opt-in to the feature