fix(wrap): resolve DM participants for correct routing

[khaliqgant]

Summary

• DMs with conv_/dm_ conversation-ID targets were being delivered to all wrapped agents instead of only the intended recipient
• Now resolves DM participants via Relaycast API with 30s cache (same pattern as main.rs) and only delivers if the wrapped agent is a participant
• Fixes case-insensitive matching for self-echo filtering and direct target checks — previously used exact HashSet::contains which missed differently-cased names

Root cause

PR #641 added a DM routing filter but whitelisted conv_/dm_ prefixed targets as pass-through. Since Relaycast delivers most DMs with conversation_id as the target (not the agent name), every wrapped agent received every DM.

Test plan

• Send a DM to a specific agent in Superset — only that agent should receive it
• Send a channel message — all subscribed agents should receive it
• cargo test --all passes (516 tests green)

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🔴 Failed DM participant resolution silently drops messages (regression from old pass-through behavior)

When get_dm_participants fails (SDK error, network issue, uninitialized client), it returns Ok(vec![]) internally (relaycast_ws.rs:726-733). This empty result is then cached for 30 seconds at wrap.rs:1367. The caller at wrap.rs:1067-1078 checks is_participant against the empty list, which is always false, causing the DM to be dropped. All subsequent DMs for that conversation are also dropped for the cache TTL duration.

The old code unconditionally allowed dm_ and conv_ prefixed targets through (!mapped.target.starts_with("dm_") && !mapped.target.starts_with("conv_")), so transient failures never caused message loss. The new code has no fallback, turning any participant-resolution failure into silent message drops.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 7 additional findings in Devin Review.

[devin-ai-integration]

🟡 Error results from DM participant resolution are no longer cached, enabling API call storms under sustained failures

The old resolve_dm_participants in src/main.rs:5256-5270 unconditionally cached the result (including vec![] from unwrap_or_else on error) for the 30-second TTL. The new resolve_dm_participants_cached only caches on the Ok path (src/helpers.rs:1055) and skips caching entirely on Err (src/helpers.rs:1058-1068). This means that when the DM participants API is failing (network issue, outage, etc.), every incoming DM for the same conversation-ID will trigger a fresh API call instead of being throttled by the 30-second TTL. Under sustained failures with many DMs, this can multiply failed API requests significantly compared to the old behaviour, which capped retries at roughly one per TTL window per conversation.

Suggested change

	Err(error) => {
	DM_DROPS_TOTAL.fetch_add(1, Ordering::Relaxed);
	tracing::warn!(
	workspace_id = %workspace_id,
	conversation_id = %conversation_id,
	error = %error,
	dm_drops_total = DM_DROPS_TOTAL.load(Ordering::Relaxed),
	"failed resolving DM participants — DM silently dropped"
	);
	vec![]
	}
	Err(error) => {
	DM_DROPS_TOTAL.fetch_add(1, Ordering::Relaxed);
	tracing::warn!(
	workspace_id = %workspace_id,
	conversation_id = %conversation_id,
	error = %error,
	dm_drops_total = DM_DROPS_TOTAL.load(Ordering::Relaxed),
	"failed resolving DM participants — DM silently dropped"
	);
	let empty: Vec<String> = vec![];
	cache.insert(cache_key, (Instant::now(), empty.clone()));
	empty
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.