newrelic / newrelic/newrelic-java-agent
GraphQL: Explore optimizations for `GraphQL/resolve/` transaction segments
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 240
- Forks
- 170
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 21
Description
The GraphQL instrumentation creates a traced method for every call of graphql.execution.ExecutionStrategy.resolveFieldWithInfo which generates a transaction segment named something like GraphQL/resolve/*.
We have seen cases where this results in thousands of such transaction segments, eventually leading to the segment_limit for transactions being exceeded, causing the transaction to be clamped (limiting data collection for the transaction).
It is debatable how valuable these GraphQL/resolve/* transaction segments actually are, so perhaps a config (or alternate approach like marking that @Trace as leaf=true) that can optionally quiet the noise would be a valuable enhancement to this instrumentation.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with instrumentation/graphql-java-22.0/src/main/java/graphql/ExecutionStrategy_Instrumentation.java and the ExecutionStrategy.resolveFieldWithInfo entry point. Trace how the @Trace annotation produces GraphQL/resolve/* segments, then evaluate the configurable and leaf-trace alternatives against the segment_limit problem. Done means selecting and implementing a clear approach that reduces noisy segments without losing needed instrumentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, java
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100