Skip to content

Require MTR pass for path success; gate target scoring and add explicit per-path MTR/ping logging#22

Merged
ehsanking merged 1 commit into
mainfrom
ehsan/fix-connection-path-score-display-logic
Apr 2, 2026
Merged

Require MTR pass for path success; gate target scoring and add explicit per-path MTR/ping logging#22
ehsanking merged 1 commit into
mainfrom
ehsan/fix-connection-path-score-display-logic

Conversation

@ehsanking
Copy link
Copy Markdown
Owner

Motivation

  • Paths were being marked successful based on connectivityScore > 0, causing false-positive "✓" even when ping 0/1 and latency were N/A because MTR/ping checks were not enforced for success.
  • Target-side score contributions could inflate connectivity scores when the target ping had failed, misrepresenting reachability.
  • Logs did not clearly show MTR state per path which made it hard to map the visual success marker to the MTR result.

Description

  • Require stageResults.mtr === 'passed' before treating a connection path as successful and adding it to providerResults.successfulConnections in testProviderConnectivity (file: iran_connectivity.js).
  • Move all target-side score contributions inside a if (results.targetPing) { ... } block in calculateConnectivityScore so ports/traceroute/MTR bonuses are only counted when the target ping succeeded.
  • Add explicit per-path ping and latency badges and append {mtr ✓} for passed MTR or {mtr <state>} for failed/skipped/unavailable states to the success/failure log lines so output matches MTR-based pass/fail semantics.
  • Changes are limited to iran_connectivity.js and preserve existing score math except for the gating and logging adjustments.

Testing

  • Ran the repository test suite with npm test -- --runInBand and all tests passed (6/6).
  • Verified the connectivity score unit tests (connectivity score includes traceroute and low-loss mtr bonuses and connectivity score remains low when all checks fail) succeeded.
  • Verified higher-level pipeline/controller tests in the suite also passed after the change.

Codex Task

@ehsanking ehsanking merged commit 11168e2 into main Apr 2, 2026
2 checks passed
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a876ba1ecc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread iran_connectivity.js
? `{latency ${pingStats.averageLatencyMs} ms}`
: '{latency N/A}';

if (isMtrPassed) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Fall back when MTR cannot run

This branch makes mtr a hard prerequisite for any successful path (stageResults.mtr must equal passed). In environments where mtr is missing or returns no parsable loss (which currently maps to unavailable/no-data), every candidate is forced into failedConnections even when ping and TCP checks succeed, so the analyzer can report zero viable providers due to tooling availability rather than network reachability. Consider gating on MTR only when the stage is actually available.

Useful? React with 👍 / 👎.

Comment thread iran_connectivity.js
if (results.mtrAvailable && results.mtrLossPercent !== null) {
if (results.mtrLossPercent <= 5) score += 5;
else if (results.mtrLossPercent <= 20) score += 2;
if (results.targetPing) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Preserve TCP scoring when ICMP is blocked

Placing all target-side score terms behind if (results.targetPing) drops the score for hosts that block ICMP but still have reachable TCP services (80/443/22/53), even though those ports are explicitly tested just above. In ICMP-filtered networks this under-scores actually reachable targets and distorts ranking/selection output; applying a ping penalty is reasonable, but zeroing all target-port contributions is a functional regression.

Useful? React with 👍 / 👎.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant