feat: emit octolens mentions under the keyword's subproject integration

[themarolt]

Summary

The Octolens mention poll now emits each mention under the Octolens integration of the subproject its keyword maps to, instead of under the poll's own integration. This is the poll side of running Octolens as one integration per mapped subproject (data access merged in #4977). The discovery schedule that creates those integrations follows in the next PR; until it ships no Octolens integration or sync unit exists, so this changes nothing at runtime yet.

Changes

• createOctolensDeps resolves a keyword to { segmentId, integrationId } with listActiveOctolensKeywordMappings, which covers the active mappings of every live subproject Octolens integration, once per sync run.
• A keyword that is active under more than one integration counts as unmapped rather than being routed to either one. Discovery never maps a keyword to two subprojects, so this only guards against misrouting.
• runMentionPoll groups mentions by integration and segment and passes both to emit. Unmapped keywords and the per-keyword backfill behave as before.
• Tests updated for the new resolution, including the two-integration case.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Performance improvement
• Chore / dependency update
• Documentation

Related issue

Refs linuxfoundation/lfx-cdp-insights-ops#748

[cursor]

PR Summary

Medium Risk
Changes mention routing and integration attribution in the Octolens sync path; wrong mapping logic could misattribute activity until discovery ships, though PR notes limited runtime impact until follow-up work lands.

Overview
Octolens mention polling now routes each mention to the subproject’s own Octolens integration, not the integration running the poll. Keyword resolution was replaced with resolveKeywordTarget, which loads all active keyword mappings via listActiveOctolensKeywordMappings and returns { segmentId, integrationId }.

Ambiguous keywords (active under more than one integration) are treated as unmapped so mentions are not misrouted. runMentionPoll groups emits by integration+segment and passes that target into ctx.emit instead of always using the poll’s integrationId. Unmapped-keyword tracking and per-keyword backfill still use the new resolver. Tests cover multi-integration ambiguity and per-target emits.

^{Reviewed by Cursor Bugbot for commit c8ff435. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Copilot]

🟢 Approval recommended

The focused changes match the existing routing contracts, with no blocking issues identified in static review; tests were not executed.

0 open findings

What changed in this PR

Routes Octolens mentions to each keyword’s subproject integration, building on the data-access support added in #4977.

Changes:

• Resolves and caches keyword targets across active integrations.
• Groups emitted mentions by integration and segment; ambiguous mappings remain unmapped.
• Updates routing and backfill tests for the new target structure.

File	Description
services/​libs/​connectors/​src/​connectors/​octolens/​syncs/​mentionPoll.ts	Emits mentions under their resolved integration and segment.
services/​libs/​connectors/​src/​connectors/​octolens/​syncs/​mentionPoll.test.ts	Updates routing assertions and backfill fixtures.
services/​libs/​connectors/​src/​connectors/​octolens/​syncs/​mappingDiscovery.test.ts	Updates the dependency mock.
services/​libs/​connectors/​src/​connectors/​octolens/​deps.ts	Resolves cached keyword targets and rejects ambiguous mappings.
services/​libs/​connectors/​src/​connectors/​octolens/​deps.test.ts	Covers target resolution, ambiguity, and caching.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.