Embedding programs/server/js/viz-standalone.js pulls a ~1.38 MiB prebuilt dependency bundle (including Graphviz object code) into the repository.

That permanently inflates git history and violates the no-large/fat-binary-in-git rule. Please avoid committing this generated bundle and instead generate/package it from source during build/release (or fetch it in packaging/CI) so the artifact is not stored in-tree.

This is tolerable. Please proceed.

This issue still holds in the current head.

programs/server/js/viz-standalone.js is a ~1.38 MiB prebuilt/minified bundle that includes third-party object code, so we are still checking a fat generated artifact into git. That conflicts with the repo rule against large/binary blobs in-tree, and it now also causes CI failure (Style check -> codespell on this file).

Please keep this asset out of the repository (generate/fetch it in build/release packaging, or vendor the source and build it as part of tooling) so we avoid permanent history bloat and style-check noise.

This is still present in the current head: programs/server/js/viz-standalone.js is a ~1.38 MiB prebuilt third-party bundle (including Graphviz object code) checked directly into the repository and embedded into the server binary. That remains a fat generated dependency artifact in git, with permanent history/binary-size cost.

Please switch to a source-based or build-time fetched artifact flow instead of committing the bundled output file.

I re-checked current head and this is still unresolved.

programs/server/js/viz-standalone.js remains a ~1.38 MiB prebuilt third-party bundle (including embedded Graphviz object code), checked directly into git and then embedded into the server binary via #embed.

The previous reply does not change the underlying invariant issue: this permanently increases repository history with a generated fat artifact instead of source-managed assets/build-time generation.

query_id alone is not a stable identifier for a single query execution. It can be reused (for example via explicit query_id settings), and in cluster mode the same query_id can appear on multiple hosts/executions.

Because the picker stores only query_id in <option value=...>, subsequent calls (fetchQueryText / fetchProfileData) can pick up rows from a different execution and merge unrelated processor stats. That breaks the page contract of showing the selected query's pipeline.

Please carry a per-execution key from the picker (for example hostname + query_id + event_time_microseconds, or another unique tuple) and filter both follow-up queries by that key (or a precise time window) instead of query_id only.

Not important, please disregard the comment above.

The ambiguity is still present in the current code.

The picker stores only query_id (<option value=...>), then both follow-up queries use only WHERE query_id = {qid:String} (fetchQueryText and fetchProfileData). If query_id is reused (manual SET query_id, retries, or cross-host duplicates in cluster mode), the selected row can resolve to another execution and blend unrelated processor stats.

Please carry an execution key from the picker (for example query_id + event_time_microseconds + hostname) and filter both follow-up reads by that key instead of query_id alone.

This is still live in the current head. The picker stores only query_id as the option value, and both follow-up queries still filter only WHERE query_id = {qid:String}. That conflates distinct executions when query_id is reused (explicit SET query_id, retries, or collisions across hosts in cluster mode), and duplicate options with the same value are not independently selectable.

Please key selection and profile lookup by a tuple that uniquely identifies one log row (for example event_time_microseconds + host + query_id, or a stable row id), and use that same tuple in both query-text and profile-data fetches.

I re-checked current head and this concern is still live.

The picker still stores only query_id as <option value=...>, and both follow-up reads still filter only WHERE query_id = {qid:String} in fetchQueryText and fetchProfileData.

The prior "not important" reply does not address the correctness issue: when query_id is reused (explicit query_id settings, retries, or multi-host contexts), the selected row in the UI is not a stable key for one execution, so the rendered text/heatmap can describe a different execution than the one the user picked.

/processors-profile is currently added only in addCommonDefaultHandlersFactory, but createHandlersFactoryFromConfig has no matching handler.type branch (unlike play, dashboard, binary, merges, and jemalloc).

That means any deployment that sets http_handlers cannot configure this endpoint at all, so the feature disappears outside default handlers. Please add a dedicated config handler type (for example processors_profile) in the config-driven switch and wire it to ProcessorsProfileWebUIRequestHandler.