fix(ws): disambiguate Meshtastic feeder WebSocket for shared API keys#384
Merged
Conversation
Mirror MeshCore feeder resolution so WebSocket and other callers can pick the correct Meshtastic ManagedNode by nodenum when one key links multiple feeders.
Accept feeder_node_id and feeder_node_id_str query params, reject ambiguous shared-key connects, and stop assigning the MC feeder when one MC and one MT share a key without disambiguators.
Describe feeder_node_id and feeder_node_id_str for shared Meshtastic keys; update OpenAPI and Redis docs for ws/nodes disambiguation.
This was referenced Jun 2, 2026
…ility Add _channel_redis_host() with configurable socket timeouts (default 30s) so channels_redis BZPOPMIN can outlive busy Redis on DB 1. Set CELERY_RESULT_EXPIRES default to 3600s to limit result-key churn.
Stop writing celery-task-meta-* keys for high-frequency scheduled tasks that do not use return values, reducing load on Redis DB 1.
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
2 participants
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.
Summary
resolve_meshtastic_feeder()so Meshtastic feeders on a sharedNodeAPIKeyare identified byfeeder_node_idorfeeder_node_id_str(parity with MeshCorefeeder_pubkey_prefixand MT HTTP ingest).NodeConsumerto reject ambiguous shared-key WebSocket connects instead of silently usingauths[0].docs/API_KEYS.md,openapi.yaml, anddocs/REDIS.md.Closes #383
Companion bot PR: pskillen/meshflow-bot#123
Backward compatibility
This change is backward compatible for the normal volunteer setup: one Meshtastic bot (or one feeder) per API key. No new query parameters are required when only one
ManagedNodeis linked to the key.?api_key=…onlyfeeder_node_idon a single-feeder key/api/packets/{node_id}/ingest/)When this is a breaking change
WebSocket connect is rejected (instead of silently joining the wrong Channels group) only when the key is ambiguous:
feeder_node_id/feeder_node_id_str. This matches pre-prod / integration-test setups; production volunteers almost always use one bot per key.feeder_pubkey_prefix— already rejected before this PR; behaviour unchanged.After API deploy, case (1) stays broken for WS until the bot PR ships (
feeder_node_idon the URL). Packet ingest for multi-feeder keys was already correct and remains so.Deploy
feeder_node_id).group=node_*in API logs; traceroute reaches only the intended feeder.Testing performed
python -m pytest Meshflow/ws/tests/ Meshflow/common/tests/test_meshtastic_feeder_auth.py -v(21 passed)black,isort,flake8on changed Python files