Skip to content

fix(config): gate Traffic Management/Status Message on correct firmware (#3491)#3493

Merged
Yeraze merged 1 commit into
mainfrom
fix/3491-traffic-mgmt-firmware-gate
Jun 16, 2026
Merged

fix(config): gate Traffic Management/Status Message on correct firmware (#3491)#3493
Yeraze merged 1 commit into
mainfrom
fix/3491-traffic-mgmt-firmware-gate

Conversation

@Yeraze

@Yeraze Yeraze commented Jun 16, 2026

Copy link
Copy Markdown
Owner

Fixes #3491.

Problem

Since 4.10.4, enabling Traffic Management appears to save in MeshMonitor but the node never persists it (and on stock firmware doesn't reboot). Other module configs save fine. Reporter is on firmware 2.7.25.

Root cause — firmware-side, not encoding

MeshMonitor encodes the traffic_management set-config correctly (verified end-to-end; added round-trip tests). The gap is firmware: the Traffic Management module + its AdminModule::handleSetModuleConfig case landed only on meshtastic/firmware develop via PR #9358 and are not in any release, including the latest pre-release v2.7.25.104df5f. Verified directly against that tag:

gh api repos/meshtastic/firmware/compare/016e68ec…(PR#9358)…v2.7.25.104df5f -q .status  → diverged
contents/src/modules/AdminModule.cpp?ref=v2.7.25.104df5f | grep -c traffic_management   → 0
contents/src/modules/TrafficManagementModule.cpp?ref=v2.7.25.104df5f                    → 404 Not Found

So a 2.7.25 node decodes the admin message but has no handler → silently doesn't persist. Before 4.10.4 the save errored (400 Invalid module type); #3464 fixed that, so the (correct) packet now actually sends — which exposed the firmware gap and made it look like a regression.

Fix

The MeshMonitor bug is the UI version gate advertising the module as editable on firmware that can't honour it:

  • supportsTrafficManagement() >= 2.7.22 → >= 2.7.26. No released firmware (≤ 2.7.25) supports it; gate above the latest release so it enables only on develop/preview builds (which report a newer version) and the first release shipping PR #9358. Comment notes to re-pin the exact release once tagged.
  • supportsStatusMessage() >= 2.7.19 → >= 2.7.20 — off-by-one found while verifying; the statusmessage handler first shipped in firmware 2.7.20 (absent in 2.7.19). (Status Message set intentionally does not reboot, so for it a no-reboot is normal.)
  • Corrected the "unsupported" notices in both config sections.

Tests

  • meshtasticManager.moduleSupport.test.ts: updated thresholds; added the 2.7.25 (issue Bug: Traffic management saved in meshmonitor but not on node #3491) case asserting Traffic Management is reported unsupported while Status Message is supported.
  • protobufService.moduleConfig.test.ts (new): round-trip encode→decode tests locking the module-config field names for trafficmanagement, statusmessage, and telemetry, so a future field-name drift (which would silently encode an empty sub-message) is caught. These also document that MeshMonitor's encoding for Traffic Management is correct.

Validation

  • New + updated tests: 18 pass
  • tsc --noEmit: clean
  • Full Vitest suite: 6503 pass, 0 fail, 0 suite failures

Note: a v2.7.26 placeholder is used for the Traffic Management gate since no release ships it yet — re-pin to the exact version once Meshtastic cuts a release containing PR #9358.

🤖 Generated with Claude Code

@Yeraze @claude
fix(config): gate Traffic Management/Status Message on correct firmwa…
83014d9 
…re (#3491)

Traffic Management saves appeared to succeed but never persisted on the node.
Root cause is firmware-side, not MeshMonitor: the traffic_management
set-config handler is develop-only (meshtastic/firmware PR #9358) and is NOT in
any release through the latest pre-release 2.7.25 — verified directly:
TrafficManagementModule.cpp does not exist at the v2.7.25 tag and AdminModule.cpp
has no traffic_management case. Such firmware decodes the admin message but
silently drops it. MeshMonitor's encoding is correct (added a round-trip test).

The MeshMonitor bug is the UI gate: supportsTrafficManagement() allowed it at
>= 2.7.22, advertising it as editable on 2.7.22–2.7.25 where it can't persist.
Raise the gate above the latest release (>= 2.7.26) so it lights up only on
develop/preview builds (which report a newer version) and the first release that
ships PR #9358; re-pin to the exact release when tagged.

Also fixes an off-by-one found while verifying: the status_message handler first
shipped in firmware 2.7.20, but supportsStatusMessage() gated at >= 2.7.19.
Corrected to >= 2.7.20. (Status Message set intentionally does not reboot.)

- meshtasticManager.ts: supportsTrafficManagement >= 2.7.26, supportsStatusMessage
  >= 2.7.20, with comments citing the firmware evidence.
- Config sections: corrected the "unsupported" notices.
- moduleSupport.test.ts: updated thresholds; added the 2.7.25 (issue #3491) case.
- protobufService.moduleConfig.test.ts: new round-trip encode tests locking the
  module-config field names (trafficmanagement, statusmessage, telemetry).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jun 16, 2026 •
edited
Loading

Copy link
Copy Markdown

Claude finished @Yeraze's task —— View job

PR Review: fix(config): gate Traffic Management/Status Message on correct firmware

Tasks:

  • Gather context and read changed files
  • Review code quality and best practices
  • Check for potential bugs or issues
  • Assess test coverage
  • Post final review

Summary

This is a well-investigated and appropriately scoped fix. The root cause analysis (firmware PR #9358 not in any release through 2.7.25) is solid, the fix is minimal and correct, and the tests are thorough. A few observations below.

Code Quality

meshtasticManager.ts (version gating — supportsTrafficManagement / supportsStatusMessage):

  • The approach is correct: gating on firmware version rather than config presence is the right call, and the JSDoc comments in firmwareVersionAtLeast and the two supports* methods (lines 12067–12111) explain why each threshold was chosen. This is exactly the kind of documentation that prevents future off-by-one mistakes.
  • parseFirmwareVersion (line 12046) strips the git suffix with /^(\d+)\.(\d+)\.(\d+)/, so 2.7.26.abc1234 correctly resolves to { major:2, minor:7, patch:26 }. The test at line 71 of the module support test file validates this. ✅
  • Minor: supportsStatusMessage and supportsTrafficManagement are public (no visibility modifier = public in TS class). The test in meshtasticManager.moduleSupport.test.ts accesses them via (mgr as any), suggesting they're intended to be private. This isn't introduced by this PR, but worth noting for a follow-up.

UI components:

  • TrafficManagementConfigSection.tsx line 182: the updated unsupported message is much clearer than "unsupported by device" — it explains exactly why (develop-only) and what's required (firmware > 2.7.25). Good UX. ✅
  • StatusMessageConfigSection.tsx line 83: updated to "Requires firmware 2.7.20 or greater" — accurate and concise. ✅
  • Both components correctly pass isDisabled through to render the dim overlay (lines 186, 87 respectively), so no interactive changes to disabled UI are possible.

Potential Issues

⚠️ v2.7.26 placeholder concern — needs a follow-up plan:

The PR body notes this explicitly: v2.7.26 is used as a placeholder since no release ships Traffic Management yet. This is a reasonable short-term choice, but there's a latent risk: if the Meshtastic project skips 2.7.26 and ships it in 2.7.27 or 2.8.0, users on those builds will see the feature as supported before it actually is — no, wait, that's the reverse. If they ship it in 2.7.26 exactly, the gate is correct. If they skip to 2.8.0 (or if the first release containing PR #9358 is 2.7.27), the gate is still fine (users on 2.7.27+ will pass >= 2.7.26). The only failure scenario is if a build is released that's labeled 2.7.26 but doesn't include PR #9358 — which would be unusual.

The comment at line 12107 says "Re-pin to the exact release once it is tagged." This is important operational hygiene. Consider opening a tracking issue or leaving a TODO marker that links to the firmware PR, so it doesn't get forgotten.

No functional bug in the current logic for the described issue.

Test Coverage

The tests are excellent:

  • meshtasticManager.moduleSupport.test.ts: Updated thresholds, added the key regression case (2.7.25 → TM unsupported, SM supported), and the getCurrentConfig().supportedModules tests covering Proto3 empty-sub-message behavior. The test at line 116 ("the issue Bug: Traffic management saved in meshmonitor but not on node #3491 case") is particularly valuable as a named regression anchor. ✅
  • protobufService.moduleConfig.test.ts (new): Round-trip encode→decode tests are the right tool to guard against silent field-name drift in createSetModuleConfigMessageGeneric. The test at line 77 ("throws on unknown module type") is a good negative test. ✅
  • Edge cases covered: git-suffix versions, undefined firmware, exact threshold (both inclusive and exclusive). ✅

One minor gap: there's no test for supportsTrafficManagement() with a version like 3.0.0 (major version bump). The firmwareVersionAtLeast comparison if (version.major !== major) return version.major > major handles this correctly, but since it's a different logic branch from the minor/patch path, a test case for it would make the coverage more complete. This is minor since the logic is straightforward.

Security / Performance

No concerns. This is a pure version-comparison gate with no external inputs or side effects. The parseFirmwareVersion regex is safe and appropriately anchored.

Overall

Approve with minor suggestions:

  1. Consider opening a tracking issue to re-pin the 2.7.26 threshold once firmware PR #9358 lands in a tagged release.
  2. (Optional/follow-up) Mark supportsStatusMessage and supportsTrafficManagement as private if they're internal-only, or expose them intentionally if they're part of the public API.

The fix is correct, minimal, well-documented, and well-tested. The PR description's root cause analysis is thorough and accurate.

| Branch: fix/3491-traffic-mgmt-firmware-gate

@Yeraze Yeraze merged commit a92b37b into main Jun 16, 2026
19 checks passed
@Yeraze Yeraze deleted the fix/3491-traffic-mgmt-firmware-gate branch June 16, 2026 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Bug: Traffic management saved in meshmonitor but not on node

1 participant

@Yeraze