…n-api-semconv
We're already doing that for `SpanNameExtractor`, `OperationMetrics`,
`ContextCustomizer`, etc., so I figured we should do the same for
`AttributesExtractor` implementation. Also, none of the implementations
have any additional public surface - aside from the builder/factory
method users can just simply use the interface everywhere.
This is another follow-up from #7616. This makes the test options class
immutable and uses `@AutoValue` and `@AutoValue.Builder`. As a result, a
bunch of the configuration/setup code for these said options now flings
around a builder instance. This isn't great, but I think it's an
incremental improvement that can be seen in the `@BeforeAll
AbstractHttpClientTest.setupOptions()` method, where the immutable
options are (finally) instantiated.
I decided splitting changes on different PRs due to there are a lot of
lines of code in tests here and it should simplify review process.
Another option is I can add additional commit to this PR with conversion
of other groovy files.
As part of discussions #7616, the idea of trying to do a more piecemeal
approach came up. A reasonable ask.
This is the first step in refactoring the http client tests. It factors
out the `HttpClientResult` inner class of the `AbstractHttpClientTest`
so that this can be reused by new test framework later. It also factors
the relevant abstract methods in the abstract class to a new type
adapter, which will also be reused.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
This PR includes updates to the SQLSanitizer, DbClientSpanNameExtractor
and SqlStatementInfo to name spans according to procedure name for CALL
statements. The updates to the naming logic are in the SqlSanitizer and
table has been renamed to identifier as using the table variable for the
procedure name would not be idiomatic. SqlStatementInfo has been updated
so that the db.sql.table attribute is not included for procedures.
Let's keep close to the SDK repo config.
I reverted some of the changes, only left those that I think make sense
anyway (e.g. comparing enums with `==`)
Related to #7107 and #7202
Support WebFlux 6.
Supporting reactor 3.5 seems pretty straightforward, the
`subscriberContext()` was deprecated in 3.4 in favor of
`contextWrite()`. In 3.5, `subscriberContext()` was removed.
This PR doesn't bump `latestDepTestLibrary` to 3.5 yet because there are
a couple of tests that succeed in 3.4 using `contextWrite()` but fail in
3.5 using `contextWrite()`.
My proposal is to review/merge this PR, and then I can ping our resident
reactor experts to see if they have thoughts on the failing tests in
3.5.
Bumps [spotless-plugin-gradle](https://github.com/diffplug/spotless)
from 6.12.0 to 6.12.1.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="718a504c12"><code>718a504</code></a>
Published gradle/6.12.1</li>
<li><a
href="c13acee213"><code>c13acee</code></a>
Published lib/2.31.1</li>
<li><a
href="552aabf876"><code>552aabf</code></a>
fix(deps): update dependency com.facebook:ktfmt to v0.42 (<a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1421">#1421</a>)</li>
<li><a
href="4063e9f6d1"><code>4063e9f</code></a>
Add support for KtLint 0.48.0 (<a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1432">#1432</a>
fixes <a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1430">#1430</a>)</li>
<li><a
href="062e835846"><code>062e835</code></a>
Bump changelogs.</li>
<li><a
href="8f7e00594d"><code>8f7e005</code></a>
spotlessApply</li>
<li><a
href="9a8ccae9ec"><code>9a8ccae</code></a>
Bump default ktfmt 0.41 -> 0.42</li>
<li><a
href="fb4277d2b1"><code>fb4277d</code></a>
Merge branch 'main-ktlint-0.48.0' into renovate/ver_ktfmt</li>
<li><a
href="b44d70d00a"><code>b44d70d</code></a>
Move changelog entries to the correct release.</li>
<li><a
href="b3d8e89002"><code>b3d8e89</code></a>
spotlessApply for 2023</li>
<li>Additional commits viewable in <a
href="https://github.com/diffplug/spotless/compare/gradle/6.12.0...gradle/6.12.1">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Fixes#7265
I took a look at the new Observation API, and I think that it still
makes sense to continue using the interceptors to implement this
instrumentation: they implement the OTel spec (which includes way more
attributes than the default observation convention implemented in
Spring), and cooperate with the Kafka client instrumentation and link
the receive and process spans together. And it's quite a simple change
in one of our interceptors, instead of rewriting everything.
(Draft because Spring Boot 3 hasn't released yet, and it is required to
run the tests. If we're not in a hurry this PR can wait a bit for that)
When a webflux filter is added which throws an exception, the
instrumentation does not currently capture the `http.status_code`.
The fix is to move `WebClientTracingFilter` from the first to the last
filter in the chain, which I think(?) is the general strategy we've
taken for other client instrumentation, e.g. so that if a filter makes
another http call it won't be suppressed.
I don't love the test coverage I added, so let me know if you have any
better suggestions?
EDIT: btw, I did archaeology to confirm that behavior (adding to the
beginning of the chain) has been in place since the webflux
instrumentation was added originally
6f472a62a0 (diff-493ad89b5bde807c90387aa2bb67eb10d3bcef6b6a388bd31e11796a6d01ac38R36)
~I'll create a tracking issue to remove these and support new versions.~
Tracking issue added to support latest project reactor 3.5.0 and revert
these limits: #7107
Trask Stalnaker
Mateusz Rzeszutek
jason plumb
Andrei Chugunov
Alex Kats
dependabot[bot]
Lauri Tulmin
jack-berg
Aaron Ai