Skip to content

Handle individual probe failures #61

Description

@MartinKolarik

Expose individual test failures consistently across all CLI output modes using status, failureSource, and rawOutput, while preserving useful infinite-ping aggregates.

Result labels

Use a shared label helper for failed results:

  • target → Target error
  • resolver → Resolver error
  • internal → Internal error
  • missing or unknown source → Error

Use Probe offline for status: offline.

Normal, live, and --ci output

For failed tests, append the failure label to the probe header and print the complete API-provided rawOutput:

> Berlin, DE, EU, Example Network (AS64500) — Resolver error
ping: example.invalid: Temporary failure in name resolution

If rawOutput is empty, still print the annotated header.

Live output should show the same annotation as soon as the individual test fails.

Offline output retains its existing raw diagnostic message.

HTTP GET failures

Process failed HTTP GET results before successful-response body formatting:

  • Print the annotated probe header.
  • Print the complete rawOutput.
  • Do not use rawBody as the primary output for a failed result.
  • Do not reduce rawOutput to its first line.
  • Leave successful HTTP output unchanged.

--latency

Successful tests continue to print their latency metrics.

Failed tests print the annotated probe header and complete rawOutput. Do not print latency fields for them.

Offline handling remains unchanged outside table mode.

Finite --table

Keep successful, in-progress, timed-out, and failed rows in their existing formats.

A failed row must continue using the existing centered spanning presentation:

Nanjing, CN, AS, Chinanet Backbone (AS4134) |                    --- Target error ---

Update offline rows to use the same centered spanning presentation:

Paris, FR, EU, Example Network (AS64500) |                    --- Probe offline ---

Additional requirements:

  • Do not include rawOutput in tables.
  • Continue showing 100% / time out statistics for finished ping results; those are not failed tests.
  • Render the completed table before returning an all-probes-failed error.
  • Reuse the existing spanning-row renderer for both failed and offline results.

--json

Return the original API response unchanged. Preserve status, failureSource, rawOutput, and all other fields exactly as received.

Infinite ping with multiple probes

When at least one probe finishes successfully, continue creating new rounds with the same probes.

For the current round:

  • A failed probe uses the centered spanning --- Target error ---, --- Resolver error ---, or --- Internal error --- row.
  • An offline probe uses the centered spanning --- Probe offline --- row.
  • Preserve that probe’s aggregate internally while the status row is visible.
  • Merge any usable partial statistics into the internal aggregate.
  • When a later round succeeds, restore the normal aggregate statistics row.
  • The restored Sent count must reflect missed or partial rounds.

Infinite ping termination

Terminate when every selected probe in a completed round is failed or offline.

This means:

  • A one-probe run terminates when that probe fails or goes offline.
  • A multi-probe run continues if at least one probe finishes.
  • A multi-probe run terminates when all probes fail or go offline.
  • The run terminates when all probes fail even if some failed results contain partial statistics.

Before returning the all-probes-failed error:

  1. Clear the live table where applicable.
  2. Print each probe’s failure or offline status.
  3. Print available rawOutput.
  4. Preserve the existing nonzero exit behavior.

API and runtime errors

Continue terminating immediately for:

  • Measurement creation failures.
  • API retrieval failures.
  • Polling deadlines.
  • Context cancellation or termination signals.
  • Other API or transport errors.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions