fix: only drop unknown-channel posts after API fallback also fails

dave · claude · dave · commit 3779f1536027 · 2026-04-01T11:52:09.000+11:00
Codex review: dropping immediately when payload.data.channel_type is missing
lost messages that the API lookup could have recovered. Now the early guard
only drops when both the event field AND the resolveChannelInfo API fallback
return unknown. The second resolveChannelInfo call hits the cache (same tick)
so no extra network request is made.

Co-Authored-By: Claude Sonnet 4.6 &lt;noreply@anthropic.com&gt;
diff --git a/extensions/mattermost/src/mattermost/monitor.ts b/extensions/mattermost/src/mattermost/monitor.ts
@@ -1020,12 +1020,20 @@ export async function monitorMattermostProvider(opts: MonitorMattermostOpts = {}
     }
     // Check channel type before marking the message as seen, so that a
     // transient unknown-channel post doesn't poison the dedup tracker.
+    // If the event has no channel_type, fall back to the API — but if that
+    // also returns nothing, drop the post.
     const channelTypeFromEvent = payload.data?.channel_type;
     if (mapMattermostChannelTypeToChatType(channelTypeFromEvent) === "unknown") {
-      logVerboseMessage(
-        `mattermost: drop post (cannot determine channel type for ${channelId}, post=${post.id ?? "?"})`,
-      );
-      return;
+      const channelInfoFallback = await resolveChannelInfo(channelId);
+      if (mapMattermostChannelTypeToChatType(channelInfoFallback?.type) === "unknown") {
+        logVerboseMessage(
+          `mattermost: drop post (cannot determine channel type for ${channelId}, post=${post.id ?? "?"})`,
+        );
+        return;
+      }
+      // channelInfoFallback.type is now set; continue with the normal path below.
+      // (resolveChannelInfo result is cached so the second call below
+      // is a cache hit — no extra network request.)
     }
     const dedupeEntries = allMessageIds.map((id) =>
       recentInboundMessages.check(`${account.accountId}:${id}`),
