Fix CLI validation of summary trend stats

[weillercarvalho]

What?

• Fix --summary-trend-stats parsing so invalid stats are rejected immediately instead of silently discarded.
• Update config_consolidation_test.go cases to expect the new CLI error path.

Why?

Users could pass malformed stats (e.g. p(101), coun, p() without any feedback; the CLI would accept them and the test would run
even though the stats were invalid. Surfacing the error when parsing flags prevents confusing, silent failures.

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass. (Ran go test ./internal/cmd; full make tests still fails on
  browser/DNS-dependent suites in this environment.)

Checklist: Documentation (only for k6 maintainers and if relevant)

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation (https://github.com/grafana/k6-docs): grafana/k6-docs#NUMBER if
  applicable
• I have updated or added an issue to the TypeScript definitions (https://github.com/grafana/k6-DefinitelyTyped/tree/master/
  types/k6): grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

#5424

[CLAassistant]

All committers have signed the CLA.

[ankur22]

Hi @weillercarvalho thanks for contributing a fix!

I wanted to understand the original issue, so as you suggested in the original issue, I:

1. Created an empty test script using export default function () {}.
2. Ran the test with k6 run empty.js --summary-trend-stats="med,avg,p(101)"

However the test didn't run and I was presented with:

ERRO[0000] invalid percentile trend stat value 'p(101)', provide a number between 0 and 100 
exit status 255

After applying the fix (which does indeed look correct) I get the same result though. What were you seeing before the fix?

[weillercarvalho]

Here is a quick explanation:

Before the patch, the CLI flag parser (getOptions()) tried to validate --summary-trend-stats, but it checked the wrong error variable. So even clearly bad values like p(101) slipped through that first gate and only failed later, when k6 run reached getConsolidatedConfig() and the config consolidation stage re-ran the same validation. That’s why @ankur22 you already saw ERRO[0000] invalid percentile… before my change: the later stage has always rejected invalid stats.

The fix just moves the failure to the place it should have always happened: as soon as the flag is parsed. We now return the validation error directly from getOptions(), and the consolidation tests were updated to expect a CLI read error for malformed stats. So the final user-facing error message didn’t change; what changed is that the CLI no longer accepts bogus stats for a moment before rejecting them. This keeps the behavior consistent across all commands that call getOptions(), not only the ones that happen to run the full consolidation pipeline.

[ankur22]

Thanks for explaining @weillercarvalho! LGTM 🚀

[codebien]

@weillercarvalho That's a good catch, thanks for contributing! 🙇 LGTM, I'll merge as soon as we have a green CI.