fix(frontend): apply validated max-nodes default to v1 flame graph output - #3
Open
1linkovdim wants to merge 1 commit into
Open
fix(frontend): apply validated max-nodes default to v1 flame graph output#31linkovdim wants to merge 1 commit into
1linkovdim wants to merge 1 commit into
Conversation
…tput The v1 frontend SelectMergeStacktraces and SelectMergeSpanProfile handlers validated max-nodes (applying the per-tenant `max_flamegraph_nodes_default` and clamping to `max_flamegraph_nodes_max`) and used the validated value for the per-query fan-out — but then built the final merged flame graph / tree with the raw request value `c.Msg.GetMaxNodes()`. When a client omits max-nodes (e.g. Grafana Explore Profiles, which only sends the parameter when set), the raw value is 0. `Tree.minValue` treats maxNodes < 1 as "no limit", so the final flame graph was emitted untruncated: the configured default was ignored and the max ceiling was bypassed (the merged tree could exceed `max_flamegraph_nodes_max`, since that limit lives in ValidateMaxNodes which the final assembly skipped). The user-visible effect is that an omitted max-nodes renders a far larger tree than an explicit one, so "other" appears to grow when you *raise* max-nodes toward the default. Fix: return the validated maxNodes from selectMergeStacktracesTree and use it for both NewFlameGraph and Tree.Bytes; use the in-scope validated maxNodes in the span-profile handler. The v2 read path already threads the validated value through TreeQuery, so this aligns v1 with v2. Diff was already correct. Adds a regression test asserting an omitted max-nodes truncates to the configured default (produces an "other" node, bounded node count) and that an explicit value above the max is rejected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.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.
Problem
On the v1 read path,
SelectMergeStacktracesandSelectMergeSpanProfilevalidate max-nodes (applying the per-tenantmax_flamegraph_nodes_defaultand clamping tomax_flamegraph_nodes_max) and use the validated value for the per-query fan-out — but then build the final merged flame graph / tree with the raw request valuec.Msg.GetMaxNodes().When a client omits
maxNodes(e.g. Grafana Explore Profiles, which only sends the parameter when it's set), the raw value is0.Tree.minValuetreatsmaxNodes < 1as "no limit", so the final flame graph is emitted untruncated:max_flamegraph_nodes_default) is ignored, andmax_flamegraph_nodes_max, because that limit lives insideValidateMaxNodes, which the final assembly skips.User-visible effect
An omitted
maxNodesrenders a far larger tree than an explicit one. So on a broad/deep query (worst ontransformed-profiles, where the injected service-name root makes a very wide tree), the top-table'sotherbucket grows when you raisemaxNodestoward the configured default — the opposite of what you'd expect — because the "default" view is actually unbounded.Repro on a fleet query (
{"nf.app"=~".*dgw.*"}, transformed-profiles): omit → 234k-node tree / 6.4Mother; explicit 16384 → 26k nodes / 8.7Mother; explicit 65536 → 7.67M; 131073 → correctly rejected. Total samples conserved throughout — it's purely truncation of the final assembly.Fix
selectMergeStacktracesTreenow returns the validatedmaxNodes;SelectMergeStacktracesuses it for bothNewFlameGraphandTree.Bytes.SelectMergeSpanProfileuses its in-scope validatedmaxNodesfor the final assembly.Diffwas already correct (it passes the validatedmaxNodestoNewFlamegraphDiff); its call sites were updated for the new helper signature.The v2 read path already threads the validated value through
TreeQuery, so this aligns v1 with v2.Tests
Adds
Test_Frontend_SelectMergeStacktraces_MaxNodesDefault:maxNodestruncates to the configured default (produces anothernode, bounded node count, not the full tree);Verified the test fails without the fix and passes with it.
go test ./pkg/frontend/... ./pkg/model/all green;gofmtclean.🤖 Generated with Claude Code