J1939: the self-traffic guard is bounded by the arbitration window, not by the transmission it exists for

[dborgards]

What

#119 stops a J1939 node raising its own application PGNs as peer traffic. During a re-claim the
address store is -1, so a second marker, _vacatedAddressStore, covers the address being given
up — gated on ClaimState == Claiming, because an unbounded marker has a strictly worse failure
mode (below).

That gate is a proxy for the thing actually wanted: has the echo of what this node transmitted
under the old address drained yet? The two coincide as long as the echo arrives within the
arbitration window. When it does not — an RX-reader backlog, or an adapter delivering late — the
claim completes, WriteAddress(B) clears the marker, ClaimState leaves Claiming, and the
still-queued frame carrying the old source address passes both guards and is raised through
MessageReceived.

Default ClaimAnnounceTimeout is 250 ms (J1939NodeOptions), so the echo has to be more than a
quarter second late for the two to come apart. It is a residual window, not a common one — but it
is the case the guard was written for, arriving slightly too late to be caught.

Not a regression, which is why it is a ticket

Before #119 every echo surfaced as peer traffic, delayed or not. #119 narrows that to "only an
echo arriving after the arbitration window closes". Nothing got worse, so by causality it does not
belong in that pull request — but the narrowing is incomplete and the reason is structural rather
than an oversight.

Raised by Codex on #119 (483324d,
discussion_r4009573748).

Why the obvious fix is the wrong one

Codex's first suggestion — keep the address until a peer claim establishes new ownership — was
considered and rejected during #119, and there is a test pinning the rejection
(A_Vacated_Address_Stops_Being_Ours_Once_The_Claim_Is_Over). An unbounded marker makes a node
that loses an address go permanently deaf to whoever holds it, because the clearing event
never has to arrive: a device with a static address that claimed once at power-up, before this
node started listening, simply never re-claims. Trading "one own broadcast is heard once, 250 ms
after a re-claim" for "a peer is never heard again" is the wrong direction.

The direction that does work

Codex's second suggestion, and the same thing the very first review comment on #119 asked for:
classify against the address associated with the transmission, not against the address current
when the frame is processed. Then the marker is not a timer at all — it lives exactly as long as
there is an outstanding transmission under the old address, which is the property wanted.

Sketch, not a decision:

• count transmissions issued under an address, decrement as their echoes are classified, and keep
  the marker while the count is above zero. Needs a way to tell an echo of our frame from a
  peer's frame with the same SA, which on a flagging adapter is IsEcho and on an unflagged one
  is not available — so the count alone would over-drop on a busy segment;
• or tag outgoing frames and match the tag on the way back, which is adapter-independent but
  touches the send path;
• or keep the current window and simply extend it by a bounded drain interval after the claim
  completes. Cheapest, and the worst of the three: it is another clock, which is what Three wall-clock-dependent tests fail intermittently across all three CI legs #92 is a
  list of.

Whatever shape it takes, it should keep A_Vacated_Address_Stops_Being_Ours_Once_The_Claim_Is_Over
green — that test is the boundary this must not cross.

Acceptance

• an echo carrying the old source address, delivered after the claim for the new address
  completes, is not raised through MessageReceived;
• a peer that legitimately holds the old address is still heard, with no claim required from it;
• the property is asserted without a wall-clock margin standing in for the drain (Three wall-clock-dependent tests fail intermittently across all three CI legs #92).

[dborgards]

Attempted in #123 and withdrawn. What it cost and what it taught

I built the counter this ticket proposes — count the application frames sent under an address whose echo has not come back, hand the debt to a drain marker when the address is given up, let that carry the guard instead of ClaimState == Claiming. Two reviewers returned seven findings in one round, two of them High, and #123 is closed rather than iterated.

The ticket said this direction "does work". It does, but not as a counter bolted beside the existing guard, which is how I read it and how I described the change to the maintainer — "a third check after them rather than a rewrite of the second". That was wrong, and the findings are the proof.

The one that ends the additive framing

The drain is over-armed on the common path (Bugbot, High). WriteAddress(null) arms the drain, but during arbitration the echo is swallowed by the existing vacated guard, which returns before the drain guard is ever reached — so the count is never spent. After the claim completes the stale debt drops real peer frames from the old address.

Echoes normally arrive inside the arbitration window. So a change aimed at a 250 ms residual window broke the ordinary case. The two guards ask the same question and cannot hold separate accounts: fixing this fuses them, and the fused thing is threaded through the claim state machine.

The one that falsifies the safety argument

The unseat path re-arms the drain for the new owner (Bugbot, High). ClearVacatedIfMatches — the escape hatch I cited as the reason the counter "cannot strand the node" — runs before WriteAddress(null) arms the drain for that same address. The peer that just won it has its first frames swallowed. The ordering is trivial to fix; that the guarantee was false as built is not trivial.

The five that constrain any replacement

#	finding	constraint it imposes
1	the PDU1 loopback carve-out (#119) delivers the frame, so the debt is never retired — every self-addressed request leaves a phantom	the two carve-outs on this guard interact; accounting cannot live only on the drop path
2	a rejected or throwing send leaves debt with no rollback	needs undoing — but a SendConfirmed that times out is not definitive, the frame may be on the wire with its echo still coming, so it cannot simply hang off the catch
3	SendCoreAsync runs on the caller's thread: it can pass its checks, be descheduled, and increment after the actor ran WriteAddress(null) — the debt lands on the new address and is wiped	registration and the address handoff must be atomic: per-address accounting, or serialised on the actor
4	only one drain address is stored, so A→B→C overwrites A's marker while A's echo is still outstanding	per vacated address, each with its own count, cleared individually or by that address's peer claim
5	(Bugbot, Medium) the aggregate of 1 and 2 — the counter only ever goes up	—

Where the replacement probably belongs

HasReclaimCrossed already asks this question for the caller: it compares the SA captured before the send against the current one after it, and throws J1939NoAddressException when the send crossed a reclaim. That is the same handoff the counter kept getting wrong, and it is already on the send path with the right information in hand. A per-address account maintained there — rather than a counter incremented on one thread and consumed on another — is the shape worth trying next.

Whether it is worth trying at all

Stated plainly, because the cost is now measured rather than guessed:

• the defect is not a regression — before fix(j1939,canopen): stop a node raising its own traffic as a peer's #119 every echo surfaced, delayed or not;
• the window is an echo delivered more than the full ClaimAnnounceTimeout late, 250 ms by default;
• the fix needs per-address accounting fused with a state machine that took six rounds on fix(j1939,canopen): stop a node raising its own traffic as a peer's #119 to stabilise.

That is a poor trade at today's priority, and the honest recommendation is to leave this open and unworked until something else makes the accounting worth building — not to take another run at it because an attempt exists.

---

Generated by Claude Code