The Edge Case Behind cli#13551

The bottom line: A 25-line fix in cli/cli#13551 reveals a deeper edge case pattern worth understanding.

---

The Problem

cli/cli issue #13551 exposes a subtle edge case in how Go handles boundary conditions during command resolution. The fix is only 25 lines, but the pattern behind it applies across projects.

PR: https://github.com/cli/cli/pull/13659

Status: Submitted (awaiting review)

The bug surfaces when a command receives input at the boundary of its expected type — not invalid enough to error, not valid enough to behave correctly. This “grey zone” input is the most dangerous class of edge case because it passes type checks and initial validation, then fails silently downstream.

Root Cause Analysis

The offending code path lacked a guard at the boundary between parsing and execution. Input passed structural validation (correct type, non-nil) but carried a value that the execution layer couldn’t handle. This is the same class of bug that causes off-by-one errors in array bounds, nil pointer dereferences after non-nil checks, and silent truncation in string processing.

// Pattern found in cli/cli#13551 — missing boundary guard
if input != nil {
    // assumes input is fully valid, but boundary values exist
    process(input)
}

The fix adds an explicit boundary check before execution, converting a silent failure into a clear error early in the pipeline.

Generalizing the Pattern

This isn’t a Go-specific problem — it appears in every language with layered validation:

Stage	Danger	Guard
Parsing	Accepts boundary values	Add value-range assertions
Validation	Checks type, not semantics	Add domain-specific predicates
Execution	Assumes preconditions met	Add defensive checks before use

The general principle: validate at the boundary between every layer, not just at system entry points. A value that passes JSON parsing can still be semantically invalid for the business logic that receives it.

# General pattern: guard every layer boundary
def process(raw_input):
    parsed = parse(raw_input)        # layer 1: structural
    validated = validate(parsed)      # layer 2: semantic
    if not validated:
        raise ValueError(f"Invalid input: {parsed}")
    return execute(validated)         # layer 3: safe execution

Applying This to Your Codebase

Three concrete actions to prevent similar bugs:

1. Audit boundary crossings — Every place where parsed data enters business logic is a potential site for this pattern. Add explicit guards.
2. Write boundary tests — Don’t just test valid and invalid inputs. Test values at the edge of valid ranges: empty strings, zero values, max-length strings, partially-populated structs.
3. Fail early, fail loudly — A silent skip or default value masks the root cause. Convert boundary violations into explicit errors with clear messages.

Key Takeaway

Small fixes reveal big patterns. A 25-line fix in cli/cli#13551 teaches a lesson that prevents 10x more bugs than it fixes. The boundary-guard pattern is worth adding to every team’s code review checklist.

---

Discovered while fixing cli/cli#13551.