Prevent Netty periodic purge tasks from inheriting context - #12499
gh-worker-dd-mergequeue-cf854d[bot] merged 2 commits into
Conversation
amarziali
added
the
tag: ai generated
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![datadog-datadog-prod-us1-2[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
More details
The advice matches only the private startThread method that has no arguments. It restores async propagation after normal and exceptional exits.
🤖 Datadog Autotest · Commit 07550cf · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 07550cf4c6
ℹ️ 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".
|
🎯 Code Coverage (details) 🔗 Commit SHA: acbd49d | Docs | View more details | Give us feedback! |
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
|
@codex review |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
🛡️ Codex Security Review · Automatically triggeredSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
amarziali
changed the title
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
Prevent Netty startup tasks from inheriting context Cover shaded Netty event executors Co-authored-by: andrea.marziali <andrea.marziali@datadoghq.com>
2 participants
What Does This Do
Prevents Netty’s lazily created event-loop maintenance tasks from inheriting the request context that happens to start the event executor.
Netty 4.0 creates a periodic purge task inside
SingleThreadEventExecutor.startThread(). When the executor starts during a traced request, that long-lived internal task can capture the request context and retainits continuation after the request completes.
Async propagation is now temporarily disabled only while the private, no-argument
startThread()method creates these internal tasks. The previous propagation state is restored on both normal and exceptionalexits.
sequenceDiagram participant Request as Traced request participant Executor as Netty event executor participant Agent as Context instrumentation participant Task as Periodic purge task Request->>Executor: first operation Executor->>Agent: enter startThread() Agent->>Agent: save propagation state Agent->>Agent: disable async propagation Executor->>Task: create periodic maintenance task Note over Task: No request context captured Executor-->>Agent: exit startThread() Agent->>Agent: restore propagation state Executor-->>Request: continue requestMotivation
The purge task belongs to the event executor, not to the request that caused its lazy initialization. Its lifecycle can span many requests, so retaining the first request’s continuation is not useful and this continuation is never closed.
Additional Notes
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]