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

未关闭
#480 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
python
领域
backend, databases

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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).
主要语言
Python
星标
1
派生
0
平均合并
19 小时 37 分钟
30 天内合并 PR
18

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

pskillen/meshflow-api 的其他 Issue

查看 pskillen/meshflow-api 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。