PacketProcessor is built with a fresh empty NodeDb, discarding handshake/NodeInfo-discovered nodes

[forkwright]

Finding

connect_and_handshake populates self.node_db with every node the radio reports during the config dump, and at runtime the NodeInfo arm of process_packet inserts further nodes into self.node_db. But the PacketProcessor that owns the topology graph and emits GeoSignals is constructed with a brand-new, empty NodeDb::new() that is never reconciled with self.node_db. Runtime NodeInfo frames are routed only to self.node_db, never to the processor. The processor therefore only ever knows the subset of nodes that appear in raw mesh packets it processes.

Evidence

crates/kerykeion/src/collector.rs:362 passes NodeDb::new(), into PacketProcessor::new, while handshake-discovered nodes were written to self.node_db (handshake::handshake_with_config(&mut conn, &mut db, ...) at line 213) and runtime NodeInfo is inserted via self.node_db.lock().await.insert(...) at line 145 — neither reaches the processor.

Why this matters

If the topology/GeoSignal emission relies on node identity, position, or user info (which NodeInfo carries: lat/lon, hw model, names), those are absent from the processor's view, producing incomplete or incorrect topology and signal attribution that mislead the operator. This contradicts the apparent intent that the processor owns signal emission; confirm against the documented design.

Desired correction

Seed the processor with the handshake known_nodes and route runtime NodeInfo updates to the processor's NodeDb (or share one Arc<Mutex<NodeDb>>). Done when: a node learned only via NodeInfo (no subsequent mesh packet) is visible to the PacketProcessor's topology, verified by a test.

[forkwright]

Investigated on verda. Premise confirmed live, but not claiming it — the correct fix is a design decision about ownership, not a patch. Recording the analysis so the next person does not repeat it.

Still live on current main (dc70325)

Line numbers have drifted from the report; the defect has not:

• collector.rs:383-384 still constructs PacketProcessor::new(NodeDb::new(), ...) — a fresh, empty db (was :362).
• collector.rs:90 builds the collector's own node_db: Arc<Mutex<NodeDb>>.
• Handshake-discovered nodes go only to the collector's copy; runtime NodeInfo is inserted at collector.rs:145 into the same copy. Neither reaches the processor.

Why it is not a small patch

This is two owners of one capability. PacketProcessor owns node_db: NodeDb by value (processor.rs:51) and reads or mutates it from ~10 synchronous methods. MeshCollector owns Arc<tokio::sync::Mutex<NodeDb>>. Both are public API: PacketProcessor::node_db()/node_db_mut() return plain references, while MeshCollector::node_db() returns the Arc<Mutex<..>>.

The issue's suggested "share one Arc<Mutex<NodeDb>>" therefore forces a choice, and both options are breaking:

1. Share a std::sync::Mutex. Keeps the processor's methods synchronous, but changes MeshCollector::node_db()'s public type from Arc<tokio::Mutex<..>> to Arc<std::sync::Mutex<..>>, breaking every .lock().await caller.
2. Share the existing tokio::Mutex. Keeps the collector's signature, but every processor method touching node_db becomes async, changing PacketProcessor's public surface and rewriting processor_tests.rs.

A third option — seed the processor from the handshake db at construction — is only half a fix: it closes the handshake gap and leaves runtime NodeInfo divergence, which would look resolved while still drifting. I am not landing that quietly.

Also worth settling as part of the decision: NodeDb derives only Debug, Default (node_db.rs:11), so any seeding approach needs Clone or a drain/merge method — a further hint that copying it around is not the intended design.

What is needed

A call on which component owns the node database. Once that is fixed, the change is mechanical. Leaving unclaimed and returning it to the pool.

[forkwright]

Fixed by #360 (merged, CI green).

PacketProcessor was constructed with NodeDb::new(), so every node learned during handshake was discarded at construction, and the main loop forwarded only PayloadVariant::Packet frames — top-level NodeInfo frames never reached the processor at all. Both halves are closed: MeshCollector::make_processor seeds the processor from the collector's populated NodeDb, and the extracted dispatch_to_processor mirrors runtime NodeInfo frames into it.

Verified live on main before the fix rather than taken from the issue text — the empty-NodeDb construction and the packet-only match arm were both still present.

Two tests, each failing against the pre-fix code because neither route existed: one asserts a NodeInfo frame with no mesh packet reaches processor.node_db(), the other that a freshly-built processor is seeded with nodes the collector already knew.