style(telemetry): cut the comments I over-wrote back to the guideline

The comments I added with the hierarchy sampling fix and the trigger change ran
to sixteen and twelve lines. The guideline is short and plain English. Rationale,
CI run numbers and the list of which relationships were affected belong in the
commit message, which is where they already are; inline they push the code apart
and go stale as soon as the reasons change.

Trimmed the sampling comment from sixteen lines to four, the re-check comment
from eight to four, _traceql_name_predicate's docstring from fourteen lines of
explanation to three, and the push-trigger comment from twelve to seven. Each
keeps what a reader needs at that line -- what the code does and the one
non-obvious reason -- and drops the history.

Comment-only: 13 insertions against 35 deletions, no statement changed.

Left alone deliberately: this file has ten pre-existing comment blocks longer
than six lines, including one added recently by another party. Rewriting someone
else's comments is not mine to do here, and the guideline is being applied to what
I wrote.

Verification: 7/7 validator tests pass; validate_telemetry.py compiles; the
workflow YAML parses, still carries no branches filter, and still lists 12 paths;
otel-naming exits 0.
This commit is contained in:
Pratik Mankawde
2026-08-27 12:46:17 +01:00
parent a14d9ac806
commit ed92501730
2 changed files with 19 additions and 51 deletions

View File

@@ -57,23 +57,13 @@ on:
default: false
push:
# No branches filter, deliberately. Branch names are not something this
# repository controls, so gating on one decides whether telemetry gets
# validated by what a branch is CALLED rather than by what it CHANGED. The
# previous list ("pratik/otel-phase*", "feature/otel-*",
# "feature/telemetry-*") silently excluded every other name, and because
# GitHub ANDs the branch and path filters the effect was total: pushes to
# pratik/otel-sync-diagnostics matched the paths below but not the branch
# glob, so this workflow was never dispatched there at all -- not queued,
# not skipped, no run to look at. Two rounds of harness fixes on that branch
# produced no signal before anyone noticed. The paths below already express
# the real question, which is whether a change can affect telemetry.
# No branches filter, deliberately: GitHub ANDs branches with paths, so a
# branch glob decides validation by what a branch is CALLED rather than by
# what it CHANGED, and a non-matching name gets no run at all. The paths
# below already ask the real question.
#
# Keep these globs pointing at paths that actually exist. Two earlier
# entries (include/xrpl/basics/Telemetry*.h, src/xrpld/app/misc/Telemetry*)
# matched zero tracked files, so a pure C++ telemetry change never
# triggered this workflow on push — only edits under docker/telemetry/**
# or to this file did.
# Keep these globs pointing at paths that exist -- two earlier entries
# matched zero tracked files, so C++ telemetry changes never triggered.
paths:
# This workflow, and the harness it runs.
- ".github/workflows/telemetry-validation.yml"