Configure basic github workflows for linting and testing#1
Closed
pawelchcki wants to merge 3 commits into
Closed
Conversation
acc0895 to
1097526
Compare
1097526 to
f2293a4
Compare
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
that referenced
this pull request
Apr 30, 2026
…v vars (#1930) # What does this PR do? This PR reads `/proc/self/environ` to populate AAS metadata (from env var) instead of using `getenv`. # Motivation `getenv` is not thread-safe. A call can crash if another thread is calling `setenv`. This will invalidate the `environ` pointers and cause a crash. ``` 0x79319d662c1d __GI_getenv (stdlib/stdlib/getenv.c:84) 0x7931996ccec6 std::sys::env::unix::getenv::{{closure}} 0x7931996ccdd5 std::env::_var_os 0x7931996d1acb std::env::_var 0x7931993daf7f <libdd_common::azure_app_services::RealEnv as libdd_common::azure_app_services::QueryEnv>::get_var 0x7931993da137 core::ops::function::FnOnce::call_once 0x7931994cbffb std::sync::poison::once::Once::call_once_force::{{closure}} 0x7931996d0557 std::sys::sync::once::futex::Once::call 0x7931994ca917 libdd_profiling::exporter::profile_exporter::ProfileExporter::new 0x79319933b201 ddog_prof_Exporter_new 0x79319b15695d Datadog::UploaderBuilder::build() 0x79319b157667 ddup_upload 0x793044b34f3a __pyx_pw_7ddtrace_8internal_7datadog_9profiling_4ddup_5_ddup_7upload(_object*, _object* const*, long, _object*) _PyErr_Occurred (/usr/src/python/Include/internal/pycore_pyerrors.h:23) _Py_CheckFunctionResult (/usr/src/python/Objects/call.c:29) _PyObject_VectorcallTstate (/usr/src/python/Include/internal/pycore_call.h:93) 0x63ceb6009738 PyObject_Vectorcall.cold (/usr/src/python/Objects/call.c:325) 0x63ceb6030406 _PyEval_EvalFrameDefault.cold (/usr/src/python/Python/bytecodes.c:2719) _PyObject_VectorcallTstate (/usr/src/python/Include/internal/pycore_call.h:93) 0x63ceb600a716 method_vectorcall.cold (/usr/src/python/Objects/classobject.c:69) 0x63ceb6009324 _PyObject_VectorcallTstate (/usr/src/python/Include/internal/pycore_call.h:93) 0x793198e47284 std::thread::_State_impl<std::thread::_Invoker<std::tuple<_PeriodicThread_do_start(periodic_thread*, bool)::{lambda()#1}> > >::_M_run() 0x793198e47f60 execute_native_thread_routine 0x79319d6b2ac3 start_thread (nptl/nptl/pthread_create.c:442) 0x79319d7448d0 __clone3 ``` Co-authored-by: gregory.leocadie <gregory.leocadie@datadoghq.com>
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
that referenced
this pull request
Jun 9, 2026
# What does this PR do?
Three related test-only fixes for flakes that surface on heavily loaded / slow CI runners (observed on CentOS and macOS-15). No production code changes — all edits are in #[cfg(test)] modules and dev-dependencies.
## Changes
1. retry_strategy.rs — virtual clock for backoff tests
The four test_retry_strategy_{constant,linear,exponential,jitter} tests measured wall-clock time around a single delay().await and asserted both a lower and upper bound (±100 ms tolerance). On macOS-15, test_retry_strategy_jitter measured 682 ms for a delay whose maximum is ~149 ms — pure scheduler overshoot.
Switched them to #[tokio::test(start_paused = true)]. Since the tests already use tokio::time::Instant and the sleep capability is tokio::time::sleep, tokio's paused clock auto-advances virtual time to the next timer deadline when the runtime is idle, so measured elapsed equals the exact slept duration — deterministic and independent of runner load. As a bonus these now run in ~2 ms instead of hundreds. Added tokio's test-util feature (required for start_paused).
2. send_data/mod.rs — widen timeout margins in the send-timeout tests
request_error_timeout_v04 / _v07 ran a real hyper request against an httpmock server, racing a 200 ms client timeout against a 500 ms mock delay. On a slow runner the 200 ms timeout could fire before the request reached the server, so httpmock recorded zero calls and assert_calls_async panicked with "No request has been received by the mock server."
Widened the margin so the request reliably lands while the timeout path is still exercised: client timeout 200 → 500 ms, mock delay 500 → 1000 ms. To keep wall time bounded despite the larger timeout, pinned a constant 100 ms retry backoff (instead of the default exponential ~3.1 s of sleeps) — max_retries stays 5, so requests_count == 6 and all other assertions are unchanged. (These can't use the paused clock from change #1, since they depend on genuine socket I/O.)
3. libdd-common/src/timeout.rs — drop an unreliable upper-bound assertion
A TimeoutManager test asserted elapsed < 100 ms after a 10 ms sleep. The lower bound (elapsed >= 10 ms) is the meaningful guarantee; the upper bound is the same wall-clock-vs-scheduling flake. Removed the upper-bound check, keeping the lower bound.
# Motivation
Several tests assert on real wall-clock elapsed time around .await points or sleeps. On a CPU-starved runner the timer fires on schedule but the task isn't scheduled back promptly, so measured elapsed time overshoots the assertion's upper bound — or, in the send tests, an aggressive client timeout fires before the request is even pushed onto the socket. These are timing races, not logic bugs.
Co-authored-by: julio.gonzalez <julio.gonzalez@datadoghq.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.