bug(nodes): duplicate ObservedNode rows from a non-atomic get-then-create

Open
  • Is something wrong?
#480 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, databases

Research direction

Start by reading packets/services/base.py and packets/receivers.py, where the issue identifies the non-atomic get-then-create. Then inspect the models and migrations to map the Meshtastic node number, unique constraint, and foreign keys that the dedupe must preserve; review the 2.2.0 migration for its fail-closed and dry-run approach. Done means preventing concurrent duplicates, safely merging existing rows before adding the partial unique index, and naming the node in the remaining error response.

Written by the indexing model from the issue text.

Description

bug tech-debt

Problem

Some Meshtastic node numbers have two or more ObservedNode rows. In pre-prod there are 38 duplicate pairs, and the prod identity backfill on 2026-11-04 reported 8 duplicate rows.

Cause (confirmed by a verifier): the node is created with a non-atomic get-then-create in packets/services/base.py and packets/receivers.py. Two packets from a new node, ingested within milliseconds of each other (0–8 ms apart in the pre-prod pairs), both miss the get and both create a row.

Effects:

  • Packet uploads that then look the node up hit MultipleObjectsReturned and return 500. The pre-prod bot log had 6 of these on 2026-11-04, and the 400 they produce doesn't name the node.
  • Ghost rows keep a synthesised Unknown Node !xxxxxxxx name while the real row has the node's name, so search and the UI can show two nodes.
  • NodeDB upserts touch .first(), so it's unpredictable which row they update.

Expected

  1. Prevent it: make the create atomic, with get_or_create backed by a unique constraint and a retry on IntegrityError.
  2. Constraint: add a unique (partial) index on the Meshtastic node number, for example meshtastic_node_id where the protocol is Meshtastic.
  3. Clean up existing rows: a data migration or management command that merges each duplicate set into one row: the one with the most history, or the oldest. It re-points every FK (packets, observations, positions, telemetry, claims, watches, and so on), keeps the best name, and deletes the extras. It needs a --dry-run, and should run before the unique index is added.
  4. Error message: the remaining 500/400 should name the node.

Notes

  • This predates the Meshtastic 2.8 work. The rows date from before 2026-11.
  • The dedupe has to run in prod, so it needs the same care as the 2.2.0 migration: fail closed, dry-run first.
  • Related: #436 (ingest correctness review), #437 (2.8: identity linking will need one row per node number).
Dominant language
Python
Stars
1
Forks
0
Avg merge
23h 9m
Merged PRs (30d)
15

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pskillen/meshflow-api

All issues in pskillen/meshflow-api

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.