Repository navigation
[Bug]: Ignore stale APRS callbacks after tracking stop or reconfiguration #22
Description
Activity
Implementation started on branch fix/lab-correctness-batch after reviewing the canonical APRS contract. The change will generation-gate asynchronous results and add stop/reconfigure race coverage without altering T56-only tracking, Object identity or receipt rules.
Implementation complete in the integration branch: APRS now uses a two-phase generation gate so stop/reconfiguration synchronously invalidates in-flight results. Stale success/failure/permanent callbacks cannot mutate coordinator state, persist a receipt or schedule retry; executor rejection and throwing transport paths release the current attempt. Generation-gate regression tests pass within the 117-test app suite. Physical T56 stop/reconfigure regression remains deferred until hardware is connected.
Implementation is ready in PR #26.
APRS attempts now carry a generation ticket invalidated synchronously by stop or reconfiguration. Stale success/failure callbacks cannot persist receipts, mutate coordinator state or schedule retries; throwing/rejected transport paths also release the logical in-flight attempt.
Cleanup now attempts
removeUpdates()even if location permission was revoked, with the expected SecurityException race handled safely.JVM gate tests pass. Physical stop/reconfigure regression remains open until T56 is attached.
Problem
An APRS HTTPS request that was already in flight can complete after tracking is stopped or reconfigured and persist stale last-success coordinates again.
Scope
Acceptance