Repository navigation
fix(filter): always build the rate limiters from the active prefs - #24
Merged
Merged
Conversation
Filter::load() returned before initialising the per-type limiters when /filter_prefs did not exist yet, and `filter reset` restored the default prefs without touching the limiters. A default Limiter has limit 0, which means "no limit": on a fresh repeater `filter on` applied none of the default rate limits (5-20 per 60 s) until the first reboot after a save, and after `filter reset` the last `filter rate` kept being enforced while `filter rate` reported the defaults. All three paths (constructor, resetPrefs, load) now end in initLimiters(). Test: test_filter_limits drives Filter through load/handleCommand/ allowPacketForward on the native env. That is the first test that compiles Filter.cpp natively; it needed `constrain` in the Arduino mock.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was wrong
On a repeater that has never saved filter settings,
filter onapplied no rate limits at all. The defaults (5–20 packets per 60 s per type) only took effect after a save and a reboot.filter resethad the reverse problem: it restored the default prefs but kept enforcing the lastfilter ratesetting, whilefilter ratealready showed the defaults.Cause:
Filter::load()returned before setting up the per-type limiters when/filter_prefsdid not exist, andresetPrefs()never touched them. A defaultLimiterhas limit 0, which means unlimited.Fix
The constructor,
resetPrefs()andload()now all end in oneinitLimiters(), which builds the limiters from the active prefs.Test
test_filter_limitsdrivesFilterthroughload→handleCommand→allowPacketForward. Both cases fail before the fix (6 of 6 packets forwarded, limit 5) and pass after it.Filter.cppon thenativeenv. It neededconstrainintest/mocks/Arduino.h(Arduino's macro) and a stub for theIdentityconstructor in the test.pio test -e native -e native_region_gating: 269/269 pass locally. On Windowstest_kiss_modemexits with 0xC0000139 (a DLL entry-point error); the same happens without this change.Notes
Filter.cppand has the same bug; it gets the fix with the next dmc-dev → observer merge.🤖 Generated with Claude Code