Resend-give-up: 'after N attempts' value varies 5/6/1 across the session — meaningful or counter glitch?

[rolker]

Observation

During the 2026-05-19 deployment the Giving up on resend of packet NNNNNN from remote 'X' after N attempts (first requested ~5.00X s ago, sender TTL is 5 s) warning was logged at very high rate (~hundreds to thousands per second) by udp_bridge on both salmon (operator) and gabby (boat) sides. The N value varied across the session while the sender TTL stayed constant at 5 s:

Operator side (salmon, observing operator → bizzy resends)

Time (EDT)	Phase	N	Source
12:30	WiFi up, pre-Phase-1 baseline	5	salmon §11
12:53	First 60 s after WiFi-down cutover	6	salmon §14
14:10	Recovery time	1	salmon §15

Packet IDs in the WARN samples went 1.97 M @ 12:53 → 1.69 M @ 14:10, which suggests a sender-side counter reset somewhere mid-session — possibly a bridge restart on gabby (not directly verified from salmon).

Boat side (gabby, observing bizzy → operator resends)

Time (EDT)	Phase	N	Source
12:30	Pre-launch	6	gabby §3
12:50	WiFi-up baseline	(6 implied — cumulative 9 927)	gabby §9
12:54	Post-WiFi-down	1	gabby §9 (most striking change)

Question

Is the N value meaningful and accurately reflecting the protocol's behavior, or is it tracking something other than what its message implies?

Three possible readings:

1. Real adaptive behavior: N is a measurement of how many resend attempts the sender actually got to make before the 5 s TTL killed the packet. With operator-side WiFi down, the operator's ack path collapses → first resend attempt expires unacked → N drops to 1. WiFi-up → ack path delivers acks back → sender gets more chances → N=5 or 6. If this is the right reading, the message is correct and informative.

2. Counter-tracking glitch: the field labeled "attempts" is actually something else (e.g., resend slots in a window, retry index in a particular policy state, etc.) and the value's meaning shifts as bridge state changes. The number is consistent within a snapshot but doesn't mean the same thing across snapshots.

3. A mix: the message is accurate but the constant change at scale (thousands per second) makes it hard to interpret as anything but noise.

Why it matters

Not high-priority on its own. But (a) it would make post-mission log analysis sharper if the meaning is documented, and (b) if there's any throttling on the warning rate worth adding, this is the place to discuss it. ~670 WARN/s on salmon right after the cutover (per salmon §14 live-rate sample) is well into "fills the rosbag with one repeated message" territory.

Related

• udp_bridge#20 — Stats-timer publication stalls during Starlink-only ops (same deployment, same general code path).
• Deployment: #135 — salmon log §11/§14/§15, gabby log §3/§9, in the PR #136 bundle.
• The udp_bridge build is at the post-udp_bridge#13 (resend-loop amplification fix) baseline; this is post-fix behavior.

---

Authored-By: Claude Code Agent
Model: Claude Opus 4.7 (1M context)