Claude finished @Yeraze's task —— View job

PR Review

• Gather context and read changed files
• Review implementation changes
• Review test coverage
• Post final feedback

Summary

This is a small, focused bug fix that correctly handles repeater nodes (advType=2) in the DM view. The implementation is clean and the approach is sound. Below are observations by category.

Code Quality

MeshCoreDirectMessagesView.tsx:187 — The exclusion condition is written correctly and mirrors the existing room-server (advType=3) exclusion pattern on the same line, making the intent clear:

if (c.publicKey && !isChannelPseudoKey(c.publicKey) && c.advType !== 3 && c.advType !== 2) peers.add(c.publicKey);

Minor style note: the line is now quite long. A future reader might appreciate extracting isExcludedFromDmList(c) or ordering the advType checks together (c.advType !== 2 && c.advType !== 3) for symmetry — but this is cosmetic and not a blocker.

MeshCoreDirectMessagesView.tsx:384 — The disabled prop addition for the send bar is correct and follows the existing pattern in MeshCoreMessageStream.tsx (which gates both the <input> and <button> on the same prop):

disabled={!connected || !canSend || contactsByKey.get(selected)?.advType === 2}

No issues here.

Potential Issues

Edge case: repeater selected via message history — The sidebar exclusion in dmPeers prevents a repeater from appearing as a contact-list entry, but the dmPeers computation also sweeps messages to find peers with an existing DM thread. If a repeater key previously appeared in a toPublicKey / fromPublicKey field (e.g. from an old bug or from manual testing), it would still get added to peers via the messages loop (lines 162–181), before the contacts-based exclusion at line 186. The existing send-bar disabled check at line 384 provides defence-in-depth, but the peer would still appear in the sidebar.

You may want to apply the same filter after the messages sweep, e.g.:

// After building peers from messages, drop repeaters and room servers.
for (const key of Array.from(peers)) {
  const c = contactsByKey.get(key);
  if (c && (c.advType === 2 || c.advType === 3)) peers.delete(key);
}

This is a pre-existing gap for advType=3 as well, so it may be intentional (or the assumption is that room-server / repeater keys never appear in DM message history). Worth a comment either way.

Test Coverage

The two new tests are well-structured:

1. excludes repeater contacts (advType=2) from the DM peer list (line 423) — correctly validates both the absence of the repeater and the presence of a non-repeater in the same render, avoiding false-positives.

2. disables the send input when the selected contact is a repeater (advType=2) (line 452) — uses initialSelectedContact to simulate the "nodes view › button" navigation path and correctly asserts sendInput.disabled === true.

The expanded makeActions() mock at lines 92–97 (adding getRemoteAdminCapability, forgetRemoteCredential, getRemoteStatus, etc.) is a necessary and correct fix that prevents test failures when the MeshCoreContactDetailPanel tries to render a repeater's remote-admin section.

One minor gap: there is no test asserting that a repeater arriving via message history (not contacts) is also hidden — but as noted above, that scenario may be considered out of scope for this fix.

Security / Performance

No security concerns. No performance concerns — the advType check is O(1) per contact and the useMemo dependency array already includes contacts.

Verdict

Looks good to merge. The fix is minimal, correct, and follows the established pattern. The edge-case around repeaters appearing via message history is worth a follow-up issue but is not a regression introduced here.

Superseded by #3760, which keeps repeaters/unmessagable nodes listed with full telemetry and removes the messaging UI (showing node details instead), per maintainer direction on #3755.