Credit a restored control function for the address claim that restored it

[Arjan-Woltjer]

Mirror of AgIsoStack-plus-plus#718 for this fork. Same one-line fix; the surrounding code differs because that repo's main has since refactored this function, so the change is ported rather than cherry-picked.

The bug

update_address_table()'s restore branch returns a previously-pruned control function to controlFunctionTable because it has just announced its address — but never sets claimedAddressSinceLastAddressClaimRequest on it. The CF therefore re-enters the table already eligible for pruning, and prune_inactive_control_functions() evicts it again on the very next roll-call.

The flag is true by definition at that point: the only way to reach this branch is by processing that control function's own Address Claim message, which is exactly what the flag records. The sibling branch immediately above does precisely this for a CF already in the table.

Why it matters

It converts a single eviction into a self-sustaining cycle. While that cycle runs, the CF's table entry is repeatedly nulled, so message.get_source_control_function() stops resolving for its address and process_can_message_for_global_and_partner_callbacks() silently drops every broadcast from it — a client bound to that CF goes deaf while the device is still transmitting normally.

Found on real hardware: Teensy 4.1 running this fork at 0.1.5, Ag Leader InCommand 1200 acting as VT and TC on a New Holland tractor with the usual ECU population. Observed as unbroken is now offline → has claimed address → is now offline churn every 1–2 seconds, sustained for 300+ seconds, on a bus issuing address-claim roll-calls roughly every 3 seconds.

Full analysis and field evidence: AgIsoStack-plus-plus#717.

Notes

• Build-verified against a real teensy41 cross-compile in the downstream project that found it. Not separately field-verified in isolation, because with our other local workaround in place it is a no-op for our own partners by construction — it matters for every other CF on the bus, and for anyone who doesn't carry that workaround.
• Draft, matching the convention of my other open PRs here (Add VirtualTerminalClient::get_state() #14, Decode End of Object Pool response error bits in the log #15, Fix: carry over CF liveness when adopting an already-active VT/TC partner #16) — happy to mark ready once you've had a look, or to fold it into one of them if you'd rather take these together.
• Fix: carry over CF liveness when adopting an already-active VT/TC partner #16 on this fork remains separate: it fixes the initial adoption of an already-active partner (plus-plus#584), which is a different defect in a different function.

🤖 Generated with Claude Code