Skip to content

A dial we refuse is indistinguishable from a healthy target #185

Description

@HarryCordewener

Found while auditing the registry for SSH ports (2026-09-17); nothing in the codebase records it.

CrawlCycle.RefuseAsync writes a refused dial as succeeded: true with now + ProbeSchedule.LongestInterval. A target we never dial therefore reads as flawless: consecutive_failures = 0, a recent last_probed_at, no availability row, and nothing durable anywhere. The only evidence is a log line with roughly thirty minutes of retention.

The only way to find one today is the arithmetic the refusal happens to leave behind:

SELECT host, port, game_id IS NOT NULL AS listed, last_probed_at
FROM crawl_target
WHERE consecutive_failures = 0
  AND next_probe_at = last_probed_at + interval '7 days';

On 2026-09-17 that returned exactly two rows out of 1,677 targets — one scope refusal (#tracked separately) and one standing opt-out. Both correct; neither discoverable.

What to build. A durable, operator-facing record that we declined to dial, and when. The precedent is icon_attempt (see CLAUDE.md): our own note about our own attempt, which rule 5 does not reach because none of it enters a game's public record. A refusal must stay out of availability_interval for exactly the reason FailureCause.Refused already means something else — a real RST from a real host.

What not to build. Anything that renders on a game page. "We chose not to dial this" is a fact about us.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions