Fix TransmitHistory to improve epoch handling#10017
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adjusts how TransmitHistory reconstructs throttling state across boots to avoid incorrectly suppressing first broadcasts (notably NodeInfo) after long power-off periods, addressing #9901.
Changes:
- Stop seeding
lastMillisduringTransmitHistory::loadFromDisk()and rely on epoch-to-millis reconstruction. - Add a test helper API to set stored epoch values directly for test scenarios.
- Expand unit tests to cover the #9901 regression cases (long gap allows send; short gap still throttles).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
src/mesh/TransmitHistory.cpp |
Removes lastMillis seeding on load; adds epoch-setter helper; documents wraparound behavior. |
src/mesh/TransmitHistory.h |
Declares new setLastSentAtEpoch() helper method. |
test/test_transmit_history/test_main.cpp |
Updates existing persistence test expectations and adds regression tests for #9901 scenarios. |
|
Tested this morning with results below; overall works great! Test unit was a RAK3401 1-watt radio. First Boot after being offline for 2 days: Second Boot: Took node offline immediately and let set for 13 minutes: Powered off and back on: |
|
Testing without Bluetooth, RTC or GPS.... First Boot: Second Boot: Confirmed fixed when it's attached to a Phone, but when missing any time source it appears to not have suppression. |
… files after migration" This reverts commit eb7e5c7.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
src/mesh/TransmitHistory.h:53
getLastSentToMeshEpoch()is documented as returning "epoch seconds", buthistorycan now store boot-relative seconds whenENTRY_FLAG_BOOT_RELATIVEis set. Either adjust this comment (and/or rename the API) to reflect that the returned value may be boot-relative, or provide a separate accessor for the raw persisted timestamp vs. a true epoch value.
/**
* Get the last transmit epoch seconds for a given key, or 0 if unknown.
*/
uint32_t getLastSentToMeshEpoch(uint16_t key) const;
* Fix TransmitHistory to improve epoch handling * Enable epoch handling in unit tests * Improve comments and test handling for epoch persistence in TransmitHistory * Add boot-relative timestamp handling and unit tests for TransmitHistory * loadFromDisk should handle legacy entries and clean up old v1 files after migration * Revert "loadFromDisk should handle legacy entries and clean up old v1 files after migration" This reverts commit eb7e5c7. * Add NodeInfoModule integration for RTC quality changes and trigger immediate checks * Update test conditions for RTC quality checks
* Fix TransmitHistory to improve epoch handling * Enable epoch handling in unit tests * Improve comments and test handling for epoch persistence in TransmitHistory * Add boot-relative timestamp handling and unit tests for TransmitHistory * loadFromDisk should handle legacy entries and clean up old v1 files after migration * Revert "loadFromDisk should handle legacy entries and clean up old v1 files after migration" This reverts commit eb7e5c7. * Add NodeInfoModule integration for RTC quality changes and trigger immediate checks * Update test conditions for RTC quality checks
Closes #9901
@Xaositek please test. Also make sure you test for the original problem of devices rebooting without a real timestamp from RTC, GPS or NTP. Maybe take a RAK4631 with no GPS and reboot a second or two after the initial nodeinfo send