Skip to content
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

merge main into v2 #2930

Merged
merged 72 commits into from
Oct 21, 2024
Merged

merge main into v2 #2930

merged 72 commits into from
Oct 21, 2024

Conversation

hannahkm
Copy link
Contributor

What does this PR do?

merge the latest version of dd-trace-go (1.69.0) into v2 and resolve conflicts.

Motivation

new version went out 👍🏼

Reviewer's Checklist

  • Changed code has unit tests for its functionality at or near 100% coverage.
  • System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
  • There is a benchmark for any new code, or changes to existing code.
  • If this interacts with the agent in a new way, a system test has been added.
  • Add an appropriate team label so this PR gets put in the right place for the release notes.
  • Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.

Unsure? Have a question? Request a review!

nsrip-dd and others added 30 commits September 9, 2024 13:09
With Go 1.23 released on 2024-08-13, we drop support for Go 1.21. This
means Go 1.22 is now our minimum supported Go release. Update our CI
files to reflect our current supported Go versions, and remove pre-Go
1.22 workarounds.

In addition to the CI bumps, this PR changes/fixes a few things related to the upgrade:

- Drops the old `rand` from the tracer, now that we can depend on `math/rand/v2`.
- Uses `slices` in the appsec package.
- The `TestWrapHandlerWithResourceNameNoRace` got a new data race. Specifically,
  by bumping our `go.mod` to 1.22, we get the new 1.22 ServeMux behavior internally.
  The 1.22 ServeMux modifies the Request, introducing a race with all the goroutines
  accessing/modifying the request concurrently. Fix it by giving each goroutine its own
  request. I verified that the test still catches the intended bug by reverting the fix from
  #2204 and verifying that the test fails.
For tracking adoption of SSI for profiling, record whether the profiler
was added using Orchestrion and how the profiler was activated,
following the internal "Adding SSI information to profiles" RFC.
…Y_ENABLED` kill switch environment variable (#2861)

Co-authored-by: Juan Antonio Fernández de Alba <[email protected]>
…ityEnabled and enable reporting Code Coverage percentage. (#2866)
)

The metrics profiler insisted on at least one second between collections
for two reasons:

- To avoid a division by zero because it was doing integer division to
  convert a time.Duration to seconds, which will truncate to 0, as a
  ratio in a subsequent computation
- In case "a system clock issue causes time to run backwards"

The profiler would report an error if less than one second elapsed
between collections. In practice, this resulted in misleading error logs
because it's entirely likely for profiling to be stopped less than a
second after the last profile collection.

The restriction was not really even needed. For one, we can just do
floating-point division rather than integer division to avoid the
truncation problem.

Also, Go has had monotonic time support by default since 2017, added in
Go 1.9, and time comparison operations including time.Time.Sub, work
with respect to monotonic time. We shouldn't have any issues with
negative periods. We can ensure the period is positive just as a
defensive measure, and fail if it's negative since this may indicate a
bug in the Go runtime if it's violating the monotonicity guarantees.

Fixes #2863
The fix in #2865 was intended to suppress spurious metrics profile
errors when the profiler is stopped. It did so by relaxing the
one-second duration constraint of the metrics profiler. However,
the Windows system timer resolution is about 15 milliseconds (see
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers#controlling-timer-accuracy)
This caused the metrics profile tests from #2865 to fail because the
metrics profiler will likely be stopped in less than 15 milliseconds,
meaning we'll see 0 duration between profile collection and log an
error.

This commit actually suppresses the error by checking whether the
profiler was stopped (meaning interruptibleSleep was interrupted). If
so, and if the metrics profiler returned an error, we instead return a
sentinel error indicating that profiling was stopped. If we see that
error, we just drop the profile and don't log an error. We won't upload
the profile anyway. This way, we should only report an error from the
metrics profiler if there is _actually_ a problem with the timer.
@hannahkm hannahkm changed the title chore(everything): merge main into v2 :salute_1: merge main into v2 Oct 17, 2024
@hannahkm hannahkm marked this pull request as ready for review October 21, 2024 15:48
@hannahkm hannahkm requested review from a team as code owners October 21, 2024 15:48
@hannahkm hannahkm merged commit aae338a into v2-dev Oct 21, 2024
16 of 163 checks passed
@hannahkm hannahkm deleted the hannah/merge-v2 branch October 21, 2024 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apm:ecosystem contrib/* related feature requests or bugs
Projects
None yet
Development

Successfully merging this pull request may close these issues.