Sending a mesh message to a federation-only contact (e.g. 'Arch Dev') failed with 'Missing contact_id', especially on radio-less nodes.
Root cause: the UI gave federation-only rows a NEGATIVE placeholder contact_id (derived from a DID hash), but the backend parses contact_id as u64, so a negative value deserialized to None. The negative id also never matched the positive federation-synthetic id that federation-routed messages are stored under, so those threads looked empty.
Fixed in commit 1ea3f8d6:
Frontend derives the same positive federation-synthetic id the backend uses (federationContactId mirrors federation_peer_contact_id).
Backend send_typed_wire resolves a federation-synthetic contact_id from nodes.json when it isn't in the live mesh peer table (radio-less node), instead of bailing 'Unknown federation peer'.
Pending live deploy verification.
Sending a mesh message to a federation-only contact (e.g. 'Arch Dev') failed with 'Missing contact_id', especially on radio-less nodes.
Root cause: the UI gave federation-only rows a NEGATIVE placeholder contact_id (derived from a DID hash), but the backend parses contact_id as u64, so a negative value deserialized to None. The negative id also never matched the positive federation-synthetic id that federation-routed messages are stored under, so those threads looked empty.
Fixed in commit 1ea3f8d6:
- Frontend derives the same positive federation-synthetic id the backend uses (federationContactId mirrors federation_peer_contact_id).
- Backend send_typed_wire resolves a federation-synthetic contact_id from nodes.json when it isn't in the live mesh peer table (radio-less node), instead of bailing 'Unknown federation peer'.
Pending live deploy verification.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Sending a mesh message to a federation-only contact (e.g. 'Arch Dev') failed with 'Missing contact_id', especially on radio-less nodes.
Root cause: the UI gave federation-only rows a NEGATIVE placeholder contact_id (derived from a DID hash), but the backend parses contact_id as u64, so a negative value deserialized to None. The negative id also never matched the positive federation-synthetic id that federation-routed messages are stored under, so those threads looked empty.
Fixed in commit 1ea3f8d6:
Pending live deploy verification.