refactor(sidecar)!: Avoid a dedicated socket for crashtracker#2179
refactor(sidecar)!: Avoid a dedicated socket for crashtracker#2179bwoebi wants to merge 2 commits into
Conversation
|
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. |
📚 Documentation Check Results📦
|
🔒 Cargo Deny Results📦
|
78bf47c to
f4d9ba8
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 78bf47c88d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
eaf749d to
15ae3e8
Compare
61b955f to
d3bc905
Compare
This allows us doing an unified authentication of the socket on the sidecar side, before handing off to crashtracker. Usually the parent process would be the one connecting to the crashtracker, here it is not. This will allow custom handling, and one less endpoint to secure. The strategy chosen is upgrading to the crashtracker once an IPC socket is received. Currently we recreate a new socket, but we might also decide to reuse the existing IPC connection in future. Signed-off-by: Bob Weinand <bob.weinand@datadoghq.com>
d3bc905 to
99cefc7
Compare
|
|
||
| impl ConnectionSidecarHandler { | ||
| fn new(server: SidecarServer) -> Self { | ||
| fn new(server: SidecarServer, connection: OwnedServerConn) -> Option<Self> { |
There was a problem hiding this comment.
This always returns Some(..), right? Is the Option misleading then?
There was a problem hiding this comment.
You're right, that code went through two iterations :-D
| }; | ||
|
|
||
| // One recv() returns one datagram; a max-sized buffer avoids truncation. | ||
| let read_result = guard.try_io(|inner| { |
There was a problem hiding this comment.
Every single poll read allocates and deallocs 4MiB. Is this okay?
There was a problem hiding this comment.
Not really a big problem for crashtracker, but yeah, I should move it out of the loop to save some syscalls.
| use tokio::io::unix::AsyncFd; | ||
| use tokio::io::{AsyncReadExt, BufReader}; | ||
|
|
||
| fn dgram_pair() -> (OwnedFd, OwnedFd) { |
There was a problem hiding this comment.
This test use SOCK_DGRAM but production is SOCK_SEQPACKET. Can we make tests consistent with our prod code or is this intentional?
Signed-off-by: Bob Weinand <bob.weinand@datadoghq.com>
This allows us doing an unified authentication of the socket on the sidecar side, before handing off to crashtracker. Usually the parent process would be the one connecting to the crashtracker, here it is not. This will allow custom handling, and one less endpoint to secure.
The strategy chosen is upgrading to the crashtracker once an IPC socket is received. Currently we recreate a new socket, but we might also decide to reuse the existing IPC connection in future.
The changes to the crashtracker crate itself are kept minimal, just adding a new config for a custom socket connector, and using the existing one as default.
There's also a bit of refactoring on the sidecar side, to make it easier to take ownership of the asyncfd.