Fix OTA retry accounting and radio delivery races
Keep catalog, manifest and leaf requests pending when the local transmit queue rejects them instead of spending their network retry allowance. Keep the packet selected before CAD so work becoming due during sensing cannot bypass its own channel or pacing checks. Retire cancelled radio retries before waiting for BUSY hardware or their retry deadline. Wait for active transmission completion before applying firmware. Stop admitting new transmissions after the apply drain deadline so busy queues cannot postpone reboot indefinitely, and keep those deadlines armed across millis rollover. Retain the existing persistence-flush backoff. Add failing-before/fixed-after regression coverage for all four issues, including the production OTA apply and TX guards in CI. Validation: 1,496 native tests, 42 Python integration tests, and five firmware builds passed across ESP32-S3, nRF52, and STM32 targets.
This commit is contained in:
1 parent
b2f2b5bf02
commit
5d69aa461f
11 files changed
+312
-24
No files matched your search
@@ -419,6 +419,9 @@ OTA on either radio profile. `set ota.speed 1` restores the previous pace.
|
||||
Ordinary chat, node adverts, and USB/WiFi source transfers keep their timing.
|
||||
Local verification of a staged image and leaf comparisons keep their normal
|
||||
maintenance rate even when LoRa pacing is slow.
|
||||
If the local transmit queue cannot accept a catalog, manifest, or leaf request,
|
||||
OTA keeps it pending without consuming a network retry. Successfully queued
|
||||
requests that receive no answer still have bounded retries.
|
||||
|
||||
`ota config speed 0.5` is an equivalent setter. `ota config speed` and
|
||||
`ota speed` read the current factor; the `ota config` summary also includes it.
|
||||
|
||||
Reference in new issue
Block a user