Summary
A valid advert that renames a node can still broadcast the previous name in packetObservation.observation.resolvedSource.
handlePacket resolves the advert's exact source before handlePayloadTypeSideEffects calls UpsertNode. The packet summary and nodeUpdate can carry the new name while the packet event's preferred resolved source still carries the old one. A first advert can also miss exact live resolution until the node exists. Stored reads now resolve current names after #163.
I found this while investigating the reported stale repeater names. I will add signed-advert regression coverage and resolve live endpoints after the advert side effects, preserving invalid-signature handling, source/destination direction and duplicate observation behavior. No API/schema change is planned.
The current TXT_MSG parser already follows the protocol's destination/source byte order; it should not be reversed to work around ambiguous display names.
Summary
A valid advert that renames a node can still broadcast the previous name in
packetObservation.observation.resolvedSource.handlePacketresolves the advert's exact source beforehandlePayloadTypeSideEffectscallsUpsertNode. The packet summary and nodeUpdate can carry the new name while the packet event's preferred resolved source still carries the old one. A first advert can also miss exact live resolution until the node exists. Stored reads now resolve current names after #163.I found this while investigating the reported stale repeater names. I will add signed-advert regression coverage and resolve live endpoints after the advert side effects, preserving invalid-signature handling, source/destination direction and duplicate observation behavior. No API/schema change is planned.
The current TXT_MSG parser already follows the protocol's destination/source byte order; it should not be reversed to work around ambiguous display names.