fix(sidecar): enable test_ddog_sidecar_register_app on Windows (APMSP-2356)#1848
Draft
fix(sidecar): enable test_ddog_sidecar_register_app on Windows (APMSP-2356)#1848
Conversation
6bd5773 to
ba5ba4b
Compare
Contributor
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
This comment has been minimized.
This comment has been minimized.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1848 +/- ##
==========================================
+ Coverage 71.70% 71.83% +0.13%
==========================================
Files 429 429
Lines 67916 68082 +166
==========================================
+ Hits 48697 48905 +208
+ Misses 19219 19177 -42
🚀 New features to boost your workflow:
|
Contributor
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
…ipe IPC On Windows, a named-pipe client's CreateFileA fails immediately if the server has not yet called ConnectNamedPipe — there is no kernel-level connection backlog as Unix domain sockets provide. After daemonize() returns the child process exists but its Tokio runtime may not have entered the accept loop yet, causing test_ddog_sidecar_register_app to fail intermittently. Add connect_to_sidecar_with_retry() that retries the connection with exponential back-off (1 ms → 100 ms cap, up to 20 attempts ≈ 1.9 s total) when just_spawned is true. On non-Windows platforms is_pipe_not_ready() always returns false so the helper is a single-attempt no-op there. Remove the APMSP-2356 ignore annotation from test_ddog_sidecar_register_app so the fix is validated in CI.
Fix clippy::precedence warning in libdd-trace-utils/src/otlp_encoder/mapper.rs: the shift operator binds tighter than bitwise OR, but explicit parentheses make the intent unambiguous.
- Remove WouldBlock from is_pipe_not_ready: CreateFileA uses synchronous mode and only returns ERROR_FILE_NOT_FOUND (NotFound) or ERROR_PIPE_BUSY (ConnectionRefused); WouldBlock can never appear on this path. Add comments mapping Windows error codes to io::ErrorKind variants. - Replace unreachable post-loop connect_to_server() call with unreachable!(): every loop iteration already returns via Ok, retry, or Err arm, making the trailing call dead code. - Add "Safe to block" comment on std::thread::sleep to clarify it is called from synchronous FFI context, not from within a Tokio task.
Replace the exponential-backoff retry loop in start_or_connect_to_sidecar() with two proper Windows-native fixes that address the root cause: 1. WaitNamedPipeA in SeqpacketConn::connect(): instead of immediately returning ConnectionRefused on ERROR_PIPE_BUSY, block up to 5 s for a pipe instance to become available, then retry CreateFileA. 2. Readiness signal via named Windows event: setup_daemon_process() creates a named manual-reset event (Local\dd-sidecar-ready-<PID>), passes its name to the child via DD_SIDECAR_READY_EVENT, and returns a ReadinessWaiter that blocks on WaitForSingleObject(30 s). The child calls signal_sidecar_ready() inside acquire_listener (Tokio runtime running, listener ready) before entering the accept loop. daemonize() calls the waiter after wait_spawn() so the parent cannot connect before the pipe is guaranteed to exist. On Unix, domain sockets have a kernel-level connection backlog so neither fix is needed; setup_daemon_process returns a no-op ReadinessWaiter.
…d retry, constants
The pointer→integer→pointer round-trip (event as usize / guard.0 as HANDLE) creates a pointer with no provenance in Rust's strict provenance model, which can produce ERROR_INVALID_HANDLE (os error 6) at runtime. Store the HANDLE (*mut c_void) directly in OwnedEvent, eliminating all casts. Add `unsafe impl Send` with a SAFETY comment explaining why cross-thread use of a Windows HANDLE is valid. Also explicitly declare the winapi features used by this module (synchapi, handleapi, processthreadsapi) in Cargo.toml so they are guaranteed to be linked regardless of transitive dependencies. Fixes test_ddog_sidecar_register_app panicking with "Sidecar failed to signal readiness: The handle is invalid. (os error 6)".
The CreateEventA/WaitForSingleObject cross-process signalling was consistently returning WAIT_FAILED (ERROR_INVALID_HANDLE) in CI. SeqpacketConn::connect already has a 30-second WaitNamedPipeA retry loop that handles the child startup race naturally, so the named event is redundant. Remove it along with the SPAWN_SEQ counter, OwnedEvent RAII guard, and signal_sidecar_ready helper.
485fe3a to
a77297a
Compare
The WaitNamedPipeA retry loop added in a previous commit was not needed for the sidecar startup race: the pipe is created by the parent before daemonize() is called, so CreateFileA succeeds as soon as the child process starts (Windows queues the client connection before the server calls ConnectNamedPipe). Restore the original single-call pattern that returns ConnectionRefused on ERROR_PIPE_BUSY.
The comment referenced a WaitNamedPipeA retry loop in SeqpacketConn::connect that no longer exists. Replace with the accurate explanation: the named pipe is created by the parent before daemonize(), so the client connection succeeds immediately — Windows queues it before ConnectNamedPipe is called.
…rn types setup_daemon_process never needed to return a readiness callable — the named pipe exists before the child is spawned and Windows queues client connections at the kernel level. Revert entry.rs, unix.rs and windows.rs to their origin/main signatures (io::Result<()> / Ok(())).
…mment Revert cosmetic diff in start_or_connect_to_sidecar return statement and restore the original "Ensure unique process names" comment in setup_daemon_process on Windows.
2c29f5d to
b98b4f9
Compare
unix.rs and windows.rs were missing a blank line before Ok(()) in setup_daemon_process, diverging from origin/main.
b98b4f9 to
64185b0
Compare
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.
Problem
test_ddog_sidecar_register_appwas suppressed on Windows with#[ignore](APMSP-2356) because it was failing.The test was already passing on Windows with the current
windows.rsimplementation — the#[ignore]annotation was simply never removed.Fix
Remove the
#[cfg_attr(target_os = "windows", ignore = "APMSP-2356 ...")]attribute fromtest_ddog_sidecar_register_appso the test runs and is validated in Windows CI.Add the missing
winbase,handleapi, andprocessthreadsapiwinapi feature flags todatadog-sidecar/Cargo.tomlto match the APIs already used inwindows.rs(LocalFree,CloseHandle,OpenProcessToken,GetCurrentProcess).