Require MTR pass for path success; gate target scoring and add explicit per-path MTR/ping logging#22
Conversation
There was a problem hiding this comment.
💡 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".
| ? `{latency ${pingStats.averageLatencyMs} ms}` | ||
| : '{latency N/A}'; | ||
|
|
||
| if (isMtrPassed) { |
There was a problem hiding this comment.
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 👍 / 👎.
| if (results.mtrAvailable && results.mtrLossPercent !== null) { | ||
| if (results.mtrLossPercent <= 5) score += 5; | ||
| else if (results.mtrLossPercent <= 20) score += 2; | ||
| if (results.targetPing) { |
There was a problem hiding this comment.
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 👍 / 👎.
Motivation
connectivityScore > 0, causing false-positive "✓" even whenping 0/1and latency wereN/Abecause MTR/ping checks were not enforced for success.Description
stageResults.mtr === 'passed'before treating a connection path as successful and adding it toproviderResults.successfulConnectionsintestProviderConnectivity(file:iran_connectivity.js).if (results.targetPing) { ... }block incalculateConnectivityScoreso ports/traceroute/MTR bonuses are only counted when the target ping succeeded.{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.iran_connectivity.jsand preserve existing score math except for the gating and logging adjustments.Testing
npm test -- --runInBandand all tests passed (6/6).connectivity score includes traceroute and low-loss mtr bonusesandconnectivity score remains low when all checks fail) succeeded.Codex Task