Calling `Mono#timeout()` with a timeout value smaller than the HTTP
client timeout caused the on request/response end callbacks to be simply
discarded; and the HTTP span was never finished.
Added new "Restrict pushes that create matching branches: UNCHECKED",
which I discovered is needed during contrib release.
Removed the old `v*` branch protections since we don't need to make any
more patch releases from those old branch names anymore.
I've been having a bit of trouble with the license check in our distro
repo, and I think it's helpful for it to be a separate github action
(also for visibility).
Working PR to capture all the changes required to update to otel java
1.19.0. The new log API force allows
`:instrumentation-appender-api-internal` and
`:instrumentation-appender-sdk-internal`, but necessitates a decent
amount of refactoring as a result.
The PR points at the `1.19.0-SNAPSHOT`, which I'll update upon
publication.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
Fixes#2674 by replacing basic auth information as part of the URL with
`username:password`.
Co-authored-by: Malte <MALPI@users.noreply.github.com>
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
This seems nice for after pushing `spotlessApply` on an otherwise
approved and passing PR. I just enabled it and tried it on #6774.
(somewhat related to #6743)
Btw, I thought this was helpful explanation
> After you enable auto-merge for a pull request, if someone who does
not have write permissions to the repository pushes new changes to the
head branch or switches the base branch of the pull request, auto-merge
will be disabled. For example, if a maintainer enables auto-merge for a
pull request from a fork, auto-merge will be disabled after a
contributor pushes new changes to the pull request.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request#about-auto-merge
Related to #6734.
This first stage splits out the shared utilities in
`:instrumentation:netty:netty-common`. I'll follow it up by splitting
out `:instrumentation:netty:netty-4-common`,
`:instrumentation:netty:netty-4.1` in separate PRs. If there is
appetite, I can also split out library instrumentation for
`:instrumentation:netty:netty-4.0` and
`:instrumentation:netty:netty-3.8`, though I have no need for these.
Resolves#6779
In JMS you can have either the consumer receive span or the consumer
process span (unlike Kafka, where the process span is always there and
the receive span is just an addition) - in scenarios where polling
(receive) is used, I think it makes sense to add links to the producer
span to preserve the producer-consumer connection. Current messaging
semantic conventions don't really describe a situation like this one,
but the https://github.com/open-telemetry/oteps/pull/220 OTEP mentions
that links might be used in a scenario like this one - which makes me
think that adding links here might be a not that bad idea.
dependabot[bot]