Consumers can store a result, but cannot reliably explain failed probes, handle server admission failures, or reconstruct the settings and algorithm that produced it.
Three related omissions in the current API:
- Loaded-probe errors are logged at debug level and discarded; results expose successful samples but not attempted/failed probe counts or their causes.
- HTTP failures are formatted as strings. A scheduler cannot reliably obtain status and
Retry-After via typed errors, and a flow failure after an interval may only be reflected in the partial result/warnings.
schema_version identifies the result contract, not the measurement implementation. Results lack effective measurement options and algorithm/build provenance for comparing stored runs.
Relevant code: discarded probe errors, status errors, result contract.
Acceptance criteria:
- Expose per-kind probe attempts, successful completions, failures, and cancellation/skip distinctions with clearly defined scope relative to loaded windows.
- Preserve actionable HTTP status and valid
Retry-After information in a structured form accessible for discovery and load-phase failures, including partial results.
- Keep retry/scheduling decisions with the caller; add no automatic retries.
- Record effective measurement parameters and available algorithm/build provenance without including credentials, authorization headers, or other secrets.
- Define how provenance works when the Go library is embedded in another application, rather than assuming CLI ldflags exist.
- Keep additions compatible with existing JSON documents; use schema-version rules for any semantic changes.
- Add targeted tests for probe outcomes, 429/503 admission responses and malformed Retry-After values, partial results, provenance, and secret exclusion; update specs, schema fixtures, matrix, and changelog.
The three additions may land in separate PRs.
Related: #2, #24, INV-2, INV-3, INV-7, LIM-6, LOAD-9, RES. Confirm spec changes before commit.
Consumers can store a result, but cannot reliably explain failed probes, handle server admission failures, or reconstruct the settings and algorithm that produced it.
Three related omissions in the current API:
Retry-Aftervia typed errors, and a flow failure after an interval may only be reflected in the partial result/warnings.schema_versionidentifies the result contract, not the measurement implementation. Results lack effective measurement options and algorithm/build provenance for comparing stored runs.Relevant code: discarded probe errors, status errors, result contract.
Acceptance criteria:
Retry-Afterinformation in a structured form accessible for discovery and load-phase failures, including partial results.The three additions may land in separate PRs.
Related: #2, #24, INV-2, INV-3, INV-7, LIM-6, LOAD-9, RES. Confirm spec changes before commit.