# Issue: Tarpit handler writes to response after client disconnect without checking error

**Domain:** clavis-telemetry  
**Assignee:** @hans  
**Labels:** `violation`, `cardinal-rule-part-1`, `error-handling`  
**Priority:** Medium  
**Date:** 2026-04-08

---

## Violation

**Cardinal Rule Violated:** Part 1 — "Mandatory error handling with unique codes" AND "Every `if` needs an `else`"

Per CLAVITOR-AGENT-HANDBOOK.md Part 1:
> Mandatory error handling with unique codes:
> - Every `if` needs an `else`.

---

## Location

File: `clavis/clavis-telemetry/main.go`

Function: `tarpit()` (lines 121-148)

Lines 139-147:
```go
// Drip one byte per second for 30 seconds
for i := 0; i < 30; i++ {
    _, err := w.Write([]byte(" "))
    if err != nil {
        return // Client disconnected
    }
    if flusher, ok := w.(http.Flusher); ok {
        flusher.Flush()
    }
    time.Sleep(time.Second)
}
```

---

## The Violation

1. The `w.Write()` error is properly checked (good!)
2. But the `flusher.Flush()` error is **completely ignored**
3. No unique error code for the flush failure case

While flush errors are less common in tarpit scenarios (we're deliberately wasting scanner resources), the principle states: "Every `if` needs an `else`."

---

## Why This (Minor) Fix Matters

The tarpit is a security feature. If the flush fails:
- We might be wasting CPU cycles on a broken connection
- The scanner might detect the tarpit by timing anomalies
- We lose the "one byte per second" rate that makes tarpits effective

This is a low-severity fix, but it's about honoring the principle consistently.

---

## Required Fix

```go
for i := 0; i < 30; i++ {
    _, err := w.Write([]byte(" "))
    if err != nil {
        return // Client disconnected - expected, no log needed
    }
    if flusher, ok := w.(http.Flusher); ok {
        err = flusher.Flush()
        if err != nil {
            return // Client disconnected during flush
        }
    }
    time.Sleep(time.Second)
}
```

Note: Since tarpit is intentionally wasting resources on scanners, we don't need unique error codes for client disconnects (that's the expected outcome). But we should acknowledge the error rather than ignore it.

---

## Verification Checklist

- [ ] `flusher.Flush()` error is checked
- [ ] Early return on flush error (like write error)
- [ ] Test case verifies tarpit handles early disconnect gracefully

---

**Reporter:** Yurii (Code & Principle Review)  
**Reference:** CLAVITOR-AGENT-HANDBOOK.md Part 1, "Mandatory error handling with unique codes"