feat(n8n): propagate originating-conversation routing into workflow generator

[2-A-M]

Summary

When a workflow is generated from inside a platform conversation (e.g. a Discord DM or a Telegram chat), surface the originating channel or chat to the LLM as a ## Runtime Facts line. The user can say "post the result back to this channel" and the generated send node targets the right Discord channel ID / Telegram chat ID without having to name it — closing the long-tail of the same NL ergonomics goal that motivated #7134's missing-credentials banner.

End-to-end wiring

• client-types-chat.ts: extend N8nWorkflowGenerateRequest with optional bridgeConversationId. AutomationsView already had the id in scope (it uses it to bind the workflow to the originating conversation); now also forwards it on the generation request.

• n8n-routes.ts: when bridgeConversationId is present, read the originating conversation's tail inbound message metadata via runtime.getMemories({ roomId, tableName: \"messages\", count: 12 }), derive a TriggerContext (Discord channelId/guildId, Telegram chatId/threadId, Slack channelId/teamId), and thread it into service.generateWorkflowDraft(prompt, { triggerContext }). The helper reads both the canonical metadata.discord.{channelId,guildId} sub-object and the legacy flat discordChannelId / discordServerId fields — pre-existing schema gap (canonical wins when present, flat is the fallback so nothing today breaks).

• n8n-runtime-context-provider.ts: extend RuntimeContextProviderInput to accept the trigger context, render it as a fact line:

  This workflow was prompted from a Discord conversation in #general (id 9876543210) within "Cozy Devs" (id 1234567890). When the user references "this channel" or "back to here", target that channel ID.

  Same pattern for Telegram chats and Slack channels. Empty/missing routing data → no fact line.

Backward compatibility

• Routes still work without bridgeConversationId (no triggerContext threading, baseline behavior).
• Plugin still works with hosts that don't pass triggerContext (the optional opts arg on generateWorkflowDraft is unused — see elizaos-plugins/plugin-n8n-workflow#26).

Depends on

• Stacks on feat(app-core): n8n runtime-context provider — surface Discord guilds/channels + Gmail to workflow generator #7163 (n8n runtime-context provider). Until that merges, this PR's diff includes the dependency. Once feat(app-core): n8n runtime-context provider — surface Discord guilds/channels + Gmail to workflow generator #7163 merges, GitHub auto-rebases and the diff collapses to the trigger-context plumbing.
• Runtime depends on elizaos-plugins/plugin-n8n-workflow#26 (TriggerContext on RuntimeContextProviderInput). Host code compiles fine without the plugin upgrade; falls through cleanly until the plugin pointer bumps.

Test plan

• From a Discord DM: prompt "every weekday at 9am post the day's calendar agenda back to this channel". Inspect the deployed workflow's Discord Send node — channelId equals the originating Discord channel id, not blank, not a placeholder.
• Same prompt from a Telegram chat → Telegram Send node chatId equals the originating Telegram chat id.
• No bridgeConversationId in the request → behavior unchanged.

Out of scope (follow-up)

• Persist originChannelContext on the workflow's conversation metadata so re-runs without a fresh inbound message still target the same channel.
• Switch upstream plugin-discord/telegram from flat metadata fields to the canonical nested metadata.discord.{channelId,guildId,messageId} shape — this PR's helper handles both transitionally.

Greptile Summary

This PR wires originating-conversation routing (Discord channel/guild, Telegram chat, Slack channel) into the n8n workflow generator so the LLM can resolve "post back to this channel" without the user supplying an ID. It also introduces the n8n-runtime-context-provider service (with tests) and registers it during agent boot.

The previously-flagged P1 (fromId used as Telegram chatId fallback) has been correctly addressed — the code now skips Telegram routing rather than guess. The discordWebhookApi/googleOAuth2Api inconsistency has also been resolved. Remaining notes are P2 quality items (memory ordering comment and missing triggerContext test coverage).

Confidence Score: 5/5

Safe to merge; no blocking issues remain — all P1s from the previous review have been addressed

The Telegram fromId P1 is fixed and the discordWebhookApi/googleOAuth2Api P2 is also resolved. All remaining findings are P2: a misleading memory-ordering comment, a trivially redundant inner conditional, and missing test coverage for the new triggerContext path. None of these block correctness.

packages/app-core/src/api/n8n-routes.ts (memory ordering comment), packages/app-core/src/services/n8n-runtime-context-provider.test.ts (missing triggerContext tests)

Important Files Changed

Filename	Overview
packages/app-core/src/api/n8n-routes.ts	Adds buildTriggerContextFromConversation helper and threads triggerContext into generateWorkflowDraft; the Telegram fromId P1 has been addressed but memory ordering logic has a misleading comment
packages/app-core/src/services/n8n-runtime-context-provider.ts	New service file; surfaces Discord/Gmail/triggerContext facts to the n8n workflow generator; well-structured with caching and defensive fallbacks
packages/app-core/src/services/n8n-runtime-context-provider.test.ts	New test file covering registration, Discord facts, Gmail facts, credential filtering, network failures, and caching — but no test cases for the new triggerContext / formatTriggerContextFact path
packages/app-core/src/runtime/eliza.ts	Registers n8n runtime-context provider via ensureN8nRuntimeContextProvider; pattern mirrors existing bridge initializers; clean lifecycle management
packages/app-core/src/api/client-types-chat.ts	Adds optional bridgeConversationId field to N8nWorkflowGenerateRequest; straightforward and well-documented
packages/app-core/src/components/pages/AutomationsView.tsx	Forwards bridgeConversationId into the workflow generation request; minimal one-line change using existing in-scope variable

Sequence Diagram

sequenceDiagram
    participant Client as AutomationsView (client)
    participant Route as n8n-routes (server)
    participant Runtime as AgentRuntime
    participant CtxProvider as N8nRuntimeContextProvider
    participant Service as plugin-n8n-workflow

    Client->>Route: POST /generate {prompt, bridgeConversationId}
    Route->>Runtime: getMemories({roomId: bridgeConversationId, count: 12})
    Runtime-->>Route: Memory[] (messages)
    Note over Route: buildTriggerContextFromConversation()<br/>finds first non-agent message,<br/>reads metadata.discord / metadata.telegram / metadata.slack
    Route-->>Route: TriggerContext {source, discord/telegram/slack}
    Route->>Service: generateWorkflowDraft(prompt, {triggerContext})
    Service->>CtxProvider: getRuntimeContext({userId, relevantNodes, triggerContext})
    CtxProvider-->>Service: {facts: [This workflow was prompted from Discord...], supportedCredentials: [...]}
    Service-->>Route: WorkflowDraft (with channel IDs filled in)
    Route-->>Client: WorkflowDraft JSON

Loading

Comments Outside Diff (4)

1. packages/app-core/src/api/n8n-routes.ts, line 111-117 (link)

   fromId is not chatId in Telegram group contexts

   meta.fromId is the Telegram sender's user ID, not the chat ID. In a private DM the two happen to be the same, but in a group chat or channel the chat ID is a distinct negative integer. Using fromId as the fallback chatId will cause the generated workflow to target the individual user's DM inbox instead of the originating group, silently breaking the "post back to this channel" feature for the majority of Telegram team-chat scenarios.

   If the canonical metadata.telegram.chatId isn't populated, the safest fallback is undefined (return no Telegram trigger context) rather than a value that may route to the wrong entity.

2. packages/app-core/src/services/n8n-runtime-context-provider.ts, line 641-654 (link)

   discordWebhookApi and googleOAuth2Api silently unresolvable

   Both discordWebhookApi and googleOAuth2Api appear in MILADY_SUPPORTED_CRED_TYPES but have no corresponding entry in CRED_TYPE_FACTS. The guard if (!meta) continue at line 958 silently skips them, so they are never advertised in supportedCredentials even when the user has configured them. Either add entries to CRED_TYPE_FACTS or remove these types from MILADY_SUPPORTED_CRED_TYPES to keep the two sets consistent.

3. packages/app-core/src/services/n8n-runtime-context-provider.test.ts, line 351 (link)

   No tests for triggerContext propagation

   The test file exercises Discord facts, Gmail facts, credential filtering, caching, and network failures — but there are no test cases for the new triggerContext / formatTriggerContextFact path that this PR adds. Adding at least one test per platform (Discord channel, Telegram chat, Slack channel, and the empty-context case) would close the coverage gap and guard against regressions in the fact-line wording.

4. packages/app-core/src/api/n8n-routes.ts, line 84-89 (link)

   Memory ordering not defensively handled

   The comment notes that runtime.getMemories "typically returns most-recent-first" but also says the code "defensively handles either order." In practice, memories.find(m => m.entityId !== runtime.agentId) returns the first matching element — if the API returns oldest-first, this yields the oldest inbound message rather than the most recent one. For an active conversation this could mean routing to a stale channel/chat ID. Consider sorting by a timestamp field (if available) or explicitly documenting the assumed ordering so a future reader knows when this assumption breaks.

_{Reviews (2): Last reviewed commit: "fix(n8n): drop Telegram fromId fallback ..." | Re-trigger Greptile}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 5482b208-c32b-471e-ba34-55651bc0d7cd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}