Skip to content

Conversation

@agessaman
Copy link
Contributor

Fix: Send device discovery notifications when contact list is full

Problem

When the contact list reached MAX_CONTACTS, new device discoveries were ignored and the app was not notified. This behavior is particularly frustrating for new users who miss out on mesh discovery because of a full contacts list.

Solution

When the table is full, create a temporary ContactInfo and call onDiscoveredContact() to notify the app, matching manual-add mode behavior and send PUSH_CODE_NEW_ADVERT with the full contact info allowing the Discovery List to continue to populate.

Changes

  • BaseChatMesh::onAdvertRecv(): When num_contacts >= MAX_CONTACTS, create a temporary ContactInfo and call onDiscoveredContact() instead of returning early.
  • MyMesh::onDiscoveredContact(): Remove check for !isAutoAddEnabled() and send full contact if is_new is true.

Behavior

  • Auto-add enabled + table not full: Add contact and notify
  • Auto-add enabled + table full: Notify only with temporary ContactInfo using PUSH_CODE_NEW_ADVERT
  • Auto-add disabled: Always notify with PUSH_CODE_NEW_ADVERT (existing behavior, unchanged)

Connection checks remain in onDiscoveredContact().

…full

When the contact list reaches MAX_CONTACTS, the radio now creates a
temporary ContactInfo and calls onDiscoveredContact() to notify the
app, matching the behavior of manual-add mode. This ensures the app
always receives discovery notifications even when the contact table
is full.

Removed unused shouldNotifyAboutNewContacts() method.
Updated the onDiscoveredContact method to always send discovery notifications for new contacts, regardless of the auto-add setting. This change ensures consistent behavior in contact handling.
@recrof recrof requested a review from fdlamotte January 11, 2026 08:36
@agessaman
Copy link
Contributor Author

I just took a look at the potential impacts on meshcore_py for @fdlamotte.

  1. Packet parsing: In reader.py (lines 84-112), both CONTACT and PUSH_CODE_NEW_ADVERT packets are parsed identically, and out_path_len = -1 is handled (lines 94-95).
  2. Event handling: PUSH_CODE_NEW_ADVERT dispatches EventType.NEW_CONTACT (line 109), which is stored in _pending_contacts. This matches Liam's client pattern.

I don't think there are any code changes necessary to implement.

  • No examples directly use NEW_CONTACT events, so no example code breaks.
  • The library already distinguishes between permanent contacts (CONTACTS event) which won't be sent after contacts are full and discovered contacts (NEW_CONTACT event) which will continue to fill the discovery list.
  • The out_path_len = -1 case is handled correctly.

People writing client code will need to deduplicate NEW_CONTACT events, but I'm guessing that's already implemented to prevent repeated notifications when auto-add is turned off.

@oltaco
Copy link
Contributor

oltaco commented Jan 12, 2026

This looks good, I like the refactor. 👌
I just submitted a PR that might supercede it, #1379. I'll look at pinching the refactor!

@oltaco
Copy link
Contributor

oltaco commented Jan 13, 2026

I just double checked the logic in my PR and it looks like I already implemented this, you must have telepathic powers or something 😂

from = allocateContactSlot();
if (from == NULL) {
ContactInfo ci;
populateContactFromAdvert(ci, id, parser, timestamp);
onDiscoveredContact(ci, true, packet->path_len, packet->path);
onContactsFull();

@agessaman
Copy link
Contributor Author

Indeed you did. It needed doing, and I'm glad it is getting done. I'll leave this here and close it out when yours gets merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants